Bylo vydáno openSUSE Leap 15.1. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána verze 3.14 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 8.5. Řešeno je také několik bezpečnostních chyb. Především bezpečnostní chyby v procesorech Intel.
Byla vydána nová verze 2019.2 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek v seznamu změn. Současně byl ve verzi 2019.2 vydán také Kali Linux NetHunter (Wikipedie), tj. obrazy s nástroji z Kali Linuxu pro chytré telefony a tablety.
Vyšel webový prohlížeč Tor Browser, založený na Firefoxu (60.7) a zaměřený na ochranu soukromí, ve verzi 8.5. Mění vzhled, zlepšuje přístupnost a nově je prohlášen za stabilní na Androidu.
Byl vydán Mozilla Firefox 67.0. Přehled novinek v poznámkách k vydání a na stránce věnované vývojářům. Zdůraznit lze blokování těžby kryptoměn a otisku prohlížeče, viditelnější účet Firefoxu nebo rychlý přístup ke správci hesel.
Rozšířená podpora operačního systémy Microsoft Windows 7 skončí 14. ledna 2020. Poté je možné využít placené podpory, přejít na Windows 10 nebo prostě na Linux. Vláda Jižní Koreje zkouší Linux. Přechod na Linux včetně nákupu nových počítačů by ji měl vyjít na 655 milionů dolarů.
CZ.NIC ODVR (Otevřené DNSSEC Validující Resolvery) nově podporují vedle DNS-over-TLS (DoT) také DNS-over-HTTPS (DoH). DoH lze vyzkoušet ve Firefoxu od verze 62, Chrome od verze 66 nebo Bromite od verze 67.
Po čtyřech letech od vydání verze 2015.03 byla vydána verze 2019.05 nástroje pro tvorbu 3D modelů OpenSCAD (Wikipedie). Přehled novinek v oznámení o vydání.
Americké společnosti omezují spolupráci se společností Huawei, protože Ministerstvo obchodu Spojených států amerických přidalo Huawei na černou listinu. Omezení již oznámili Google, Qualcomm, Intel, Xilinx nebo Broadcom. Google omezí přístup k Androidu a Google Play. Existujících zařízení by se to nemělo týkat. Prohlášení společnosti Huawei.
Stav vydání jádra. Novinky ve věci čistky architektur. Odesílání paketů založené na čase.
Kernel release status. Jonathan Corbet. 14. března 2018
Současné vývojové jádro je 4.16-rc5, vydané 11. března. Linus k němu řekl: „Nadále je to celkem v normě – tento kandidát na vydání je o něco větší než rc4, ale vypadá to na obvyklý výkyv daný načasováním žádostí o začlenění a ne nějaký stav nouze.“
Současný seznam regresí v cyklu 4.16 čítá devět známých problémů.
Stabilní aktualizace: 4.15.8 a 4.14.25 byly vydány 9. března. Následovaly je 11. března aktualizace 4.15.9, 4.14.26, 4.9.87, 4.4.121 a 3.18.99.
Další stabilní aktualizace 4.15.10 a 4.14.27 byly v době psaní tohoto článku revidovány a vyšly 15. března.
An update on the architecture purge. Jonathan Corbet. 14. března 2018
V nedávném článku byla řeč o odstraňování starých, neoblíbených architektur z jádra. Od jeho napsání práce pokročily. Arnd Bergmann 14. března zaslal skupinu patchů, která odstraňuje dokonce osm architektur (blackfin, cris, frv, metag, m32r, mn10300, tile a score). Zdá se, že je předurčena do začleňovacího okna 4.17. Architektura unicore32, která byla už nějaký čas jednou nohou na popravišti, se dočkala záchrany, protože se přihlásil správce, který na ní bude dále pracovat.
Bergmann vypíchl opakující se vzorec mezi architekturami, které jsou kandidáty na vyřazení:
Nakonec se zdá, že ačkoliv se těch osm architektur mezi sebou dramaticky liší, všechny potkal stejný osud: Jediná firma se starala o produktovou řadu SoC, mikroarchitekturu CPU i softwarový ekosystém, což bylo nákladnější než si nechat licencovat novější generická jádra CPU třetí strany (typicky ARM, MIPS nebo RISC-V).
Když se započítá odstranění souvisejících ovladačů zařízení, celkem bude z jádra odebráno přes 450 tisíc řádek kódu. To naznačuje, že vydání 4.17 by klidně mohlo být menší, aspoň co do počtu řádek kódu, než 4.16 – bylo by to potřetí v historii jádra, že vydání by bylo menší než jeho předchůdce. Samozřejmě by takový milník mohl být zmařen přidáním dalších 100 tisíc řádek definic registrů GPU, ale vždycky můžeme doufat.
Time-based packet transmission. Jonathan Corbet. 8. března 2018
Když aplikace posílá data po síti, obvykle chce, aby byla přenesena co nejrychleji. Síťový kód v jádře se tomu snaží vyhovět. Jsou ale i aplikace, které potřebují, aby jejich pakety byly přeneseny v určitých časových oknech. Takovému chování se v současné době jde přiblížit na úrovni uživatelského prostoru, ovšem pracuje se na lepším řešení, které má podobu skupiny patchů odesílání paketů založeného na čase.
V řadě situací není žádoucí, aby odchozí data byla přenesena okamžitě. Příkladem budiž libovolný izochronní proud dat – řekněme zvukových nebo obrazových – ve kterém je každý datový paket aktuální právě v určitém okamžiku. V případě takových proudů odeslání předem a uložení do mezipaměti na straně příjemce obecně funguje docela dobře. Ale aplikace řízené v reálném čase nemusejí být tak flexibilní. Například příkazy pro výrobní linku nebo automobilový systém by měly být přeneseny v krátkém časovém úseku. Aplikace reálného času samozřejmě mohou počkat na otevření okna před seřazením dat k přenosu, ale jakákoliv latence, která se vkrade (například kvůli velkému zatížení sítě), může způsobit, že data budou přenesena příliš pozdě.
Komunita tvořící síťové standardy přirozeně pracuje na různých řešeních tohoto problému. Jedno z nich se nazývá P802.1Qbv. Jestli vám to přijde jako jazykolam, alternativní název je stručnější: „Standard for Local and Metropolitan Area Networks-Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks Amendment: Enhancements for Scheduled Traffic.“ Definuje mechanismus, kterým se vyprázdní fronty paketů tak, že každý paket je odeslán v daném termínu. Při použití P802.1Qbv mohou aplikace pakety řadit do fronty, kdykoliv jsou připravené, ale k odeslání nedojde, dokud se nepřiblíží příslušný termín.
Skupina patchů, která v Linuxu implementuje odesílání založené na čase, se skládá z několika oddělený částí. První přidává API, které aplikacím umožňuje, aby si dané chování vyžádaly. To se dělá tak, že se systémovým voláním setsockopt() nastaví nová volba SO_TXTIME. Pakety určené k načasovanému přenosu by se měly posílat pomocí sendmsg(), a to s hlavičkou řídící zprávy (typu SCM_TXTIME) obsahující závěrečný termín k přenosu v nanosekundách jako 64bitovou hodnotu.
Pomocí sendmsg() jde nastavit ještě pár dalších parametrů řídících zpráv. SCM_DROP_IF_LATE síťovému kódu říká, že má paket prostě zahodit, není-li z nějakého důvodu možné odeslat ho včas. Zpráva SCM_CLOCKID se hodí k určení, které hodiny se mají k časování paketů používat. Výchozí hodnota je CLOCK_MONOTONIC. Zdá se ale, že tento parametr se ve skutečnosti v současné implementaci nepoužívá – až na jednu malou výjimku popsanou níže.
Uvedené změny ústřední části síťového kódu umožňují nastavení chování založeného na čase, ale toto chování samotné neimplementují. To je věc doplňkové funkcionality. Jedna možnost, jak se k ní dostat, jsou pravidla řazení (queuing discipline) tbs, jež jsou také součástí skupiny patchů. Dají se nastavit, aby plánování založené na čase používala pro konkrétní frontu, a to s několika dalšími parametry. I zde lze určit ID hodin. Pokud se ID hodin objevuje také v jednotlivých paketech, musejí se obě ID shodovat, jinak budou pakety zahozeny. Další parametr, pojmenovaný delta, slouží k nastavení, jak dlouho před závěrečným termínem se mají jednotlivé pakety odesílat na síťové rozhraní k přenosu. Tento parametr a termíny jednotlivých paketů tedy určují okno, v němž by paket měl být poslán po drátě.
Pomocí delty a příznaku SCM_DROP_IF_LATE jde docílit dvou diametrálně odlišných druhů chování. Je-li příznak nastavený a delta přiměřeně velká, myslí se tím, že paket musí být vyslán na cestu před daným termínem. Naopak s malou (či nulovou) deltou a bez nastaveného příznaku SCM_DROP_IF_LATE je chování takové, že paket nebude odeslán, dokud termín nenastane.
Implementace pravidel řazení tbs sama o sobě spoléhá na „největší úsilí“ (best effort), jelikož stále existuje riziko, že pakety budou zpožděny poté, co je tbs vypustí na síťovém rozhraní. Skutečným záměrem P802.1Qbv je ale, zdá se, implementace přímo v síťových adaptérech. Je-li adaptér obeznámen s termíny k přenosu paketů, může si naplánovat přenosy, aby zajistil, že pakety vyrazí v patřičnou dobu.
Pravidla řazení tbs tudíž podporují přenesení (offloading) odesílání založeného na čase na hardware. Skupina patchů zahrnuje implementaci pro ovladač Ethernetu igb od Intelu. V případě úplného přenesení se namísto použití parametrů delta a ID hodin předpokládá, že všechny termíny jsou odvozené od interních hodin adaptéru a tím pádem adaptér zcela přebírá odpovědnost za načasování paketů. Pokud ale tyto parametry uvedeny jsou, tbs raději seřadí pakety a na začátku okna pro odesílání je pošle rozhraní, které i v tomto případě převezme odpovědnost za vyslání před uplynutím termínu. Jelikož tento režim používá jak jaderné hodiny, tak hodiny adaptéru, oboje musejí být synchronizovány, nebo se dostaví nežádané výsledky.
Skupina patchů je v současné době ve stádiu třetí revize. Původní verzi dodal Richard Cochran, ale nyní už se o to stará Jesús Sánchez-Palencia, který provedl řadu změn a přidal možnost přenesení odpovědnost na hardware. Zatím panují nějaké neshody o tom, jak by mělo fungovat API a především zda je opravdu potřeba mít možnost určit různé hodiny. Ukládání ID hodin v každém paketu totiž zvětšuje strukturu síťového kódu sk_buff, což je něco, čemu se vývojáři síťování už nějaký čas urputně brání. Bude trvat ještě aspoň jednu revizi, než se to vyřeší, takže není jasné, zda to tato skupina patchů stihne do začleňovacího okna 4.17.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
