Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
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