Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Wayfire, kompozitní správce oken běžící nad Waylandem a využívající wlroots, byl vydán ve verzi 0.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.
Před necelými čtyřmi měsíci byl Steven Deobald jmenován novým výkonným ředitelem GNOME Foundation. Včera skončil, protože "nebyl pro tuto roli v tento čas ten pravý".
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
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).
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
6.6.2014 11:18
6.6.2014 11:36
6.6.2014 15:54