Neziskové průmyslové konsorcium Khronos Group vydalo verzi 3.1 specifikace OpenCL (Open Computing Language). OpenCL je průmyslový standard pro paralelní programování heterogenních počítačových systémů.
Homebridge pro integraci chytrých domácích zařízení byl vydán ve verzi 2.0.0. Nově vedle protokolu HomeKit Accessory Protocol (HAP) podporuje standard chytré domácnosti Matter.
Omarchy je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 3.7.0 - The Gaming Edition. Z novinek lze vypíchnout příkaz omarchy a celou řadu herních možností.
CyberChef byl vydán v nové major verzi 11. Přehled novinek v Changelogu. CyberChef je webová aplikace pro analýzu dat a jejich kódování a dekódování, šifrování a dešifrování, kompresi a dekompresi, atd. Často je využívaná při kybernetických cvičeních a CTF (Capture the Flag).
Byla vydána nová verze 2.4.67 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 11 zranitelností.
Brush (Bo(u)rn(e) RUsty SHell) je v Rustu napsaný shell kompatibilní s Bash (Bourne Again SHell). Vydána byla verze 0.4.0.
Google zveřejnil seznam 1 141 projektů (vývojářů) od 184 organizací přijatých do letošního, již dvaadvacátého, Google Summer of Code. Přihlášeno bylo celkově 23 371 projektů od 15 245 vývojářů ze 131 zemí.
Na čem pracovali vývojáři GNOME a KDE Plasma minulý týden? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Open source počítačová hra na hrdiny NetHack (Wikipedie, GitHub) byla vydána v nové verzi 5.0.0. První verze této hry byla vydána v roce 1987.
Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
NetworkManager a Avahi jsou první věci, co odstraním z nově nainstalovaného systému. ~root.cz, diskuzeNetworkManager považuju za dobrý kus software, jeho kód se mi zdá přehledný a (po pár hodinách nevěřícného civění) celkem srozumitelný. IPv6 je z mého pohledu dobře navržený a použitelný pokračovatel IPv4. Tak v čem je tedy problém?
Tiskni
Sdílej:
Platnost záznamu RDNSS by logicky měla být delší než perioda oznamování směrovače. Právě kvůli ztraceným packetům. Takže nastavovat platnost na spodní mez je hloupost. Obzvlášť pokud správce ví, že síť má nespolehlivou linku.
Samozřejmě, že stanice by si mohla aktivně pomoci požadavkem na směrovač, když vidí, že platnost se tenčí a router hraje mrtvého brouka.
Že se více ztrácí multicastové rámce znamená, že jsou špatně napsány ovladače. Především lze obvinit AP, protože to má pod palcem, kdo kdy bude mluvit.
A neodpustím si rýpnutí do network manageru. Pokud se mi ztratí nastavení resolveru, tak je to nemilé, ale rozhodně to není konec světa. IP funguje i bez DNS. Takže network manager a ostatní aplikace by se měly podle toho chovat.
Platnost záznamu RDNSS by logicky měla být delší než perioda oznamování směrovače. Právě kvůli ztraceným packetům. Takže nastavovat platnost na spodní mez je hloupost. Obzvlášť pokud správce ví, že síť má nespolehlivou linku.A co jsem asi psal? Ale radvd to dělá „by default“ alespoň ve starších verzích, a RFC to právě posvěcuje.
Samozřejmě, že stanice by si mohla aktivně pomoci požadavkem na směrovač, když vidí, že platnost se tenčí a router hraje mrtvého brouka.A může to udělat případně i vícekrát, což je řešením problému na klientské straně. Stejně jako znásobení platnosti je řešením na straně serverové. Protože už je to v reálných nasazeních, mám za to, že je problém třeba řešit překvapivě na obou stranách zároveň a tím snížit pravděpodobnost výpadku.
Že se více ztrácí multicastové rámce znamená, že jsou špatně napsány ovladače. Především lze obvinit AP, protože to má pod palcem, kdo kdy bude mluvit.V mém případě nějaký TP-Link s originálním firmware.
A neodpustím si rýpnutí do network manageru. Pokud se mi ztratí nastavení resolveru, tak je to nemilé, ale rozhodně to není konec světa. IP funguje i bez DNS.Z pohledu uživatele je internet bez DNS nefunkční. Podle toho by se měl NetworkManager chovat především. A to dělá. Nemám nic proti tomu, aby existovala volba, která nastaví, aby byl NM tolerantní vůči chybějícímu DNS, ale výchozí nastavení musí být tak jak je. Pokud jsem v kódu něco nepřehlédl, tak ale NM zachází o kousek dál. Jemu k zahození spojení stačí zrušení posledního DNS serveru z RA. Tedy nepomůže, když ještě zůstal DNS server z DHCPv6 či DHCPv4. Ale i s tím už jsem se smířil. Beru to tak, že ztráta nastavení v kontextu RA znamená radikální změnu stavu spojení, a spouští rekonfiguraci.
Z pohledu uživatele je internet bez DNS nefunkční. Podle toho by se měl NetworkManager chovat především. A to dělá.
S tím nemůžu souhlasit. Je to stejně chybná automagie, jako že ULA adresa neznamená zkonfigurovanou síť. Akorát vede k podivnostem, kdy aplikace odmítne fungovat, třebaže DNS v ten okamžik vůbec nepotřebuje (například SIP klient, který směruje přes outbound proxy), nebo kdy jedna aplikace bude tvrdit, že „není připojení“, zatímco druhá bude vesele pokračovat v datovém přenosu.
Podle mě by systém měl být schopen co nejvíce využít dostupných služeb, a ne se upnout na jednu vlastnost a z ní kategoricky něco vyvozovat. Chce se mi opakovat Linusovo hodnocení Gnome jako systému pro idioty.
S tím nemůžu souhlasit. Je to stejně chybná automagieZadej DNS jméno zdroje, který má být dostupný, a uvidíš, že to nebude fungovat.
jako že ULA adresa neznamená zkonfigurovanou síť.ULA je úplně něco jiného, viz výše. Zadej název toho, co má fungovat. Pokud to selže, síť z pohledu uživatele nefunguje.
Akorát vede k podivnostem, kdy aplikace odmítne fungovat, třebaže DNS v ten okamžik vůbec nepotřebuje (například SIP klient, který směruje přes outbound proxy), nebo kdy jedna aplikace bude tvrdit, že „není připojení“, zatímco druhá bude vesele pokračovat v datovém přenosu.Jo s tím souhlasím, k podivnostem to vede. Ale pokud chceš vést diskuzi o tom, co je a není správné řešení, tak nejdřív musíš zadefinovat cíle. Bez toho nelze posoudit, jestli je systém splňuje.
Podle mě by systém měl být schopen co nejvíce využít dostupných služeb, a ne se upnout na jednu vlastnost a z ní kategoricky něco vyvozovat.A právě tohoto cíle za některých okolností NM dosahuje tím, že zahodní nefunkční spojení, aby ho nahradil funkčním. A za jiných okolností ho zase nedosahuje. Bohužel se zatím do počítačů nedodávají křišťálové koule.
Chce se mi opakovat Linusovo hodnocení Gnome jako systému pro idioty.Tak to budeš mít docela problém, protože NetworkManager jaksi není specifický pro Gnome ;). Nehledě na to, že hodnotit desktopová rozhraní podle toho, co o nich řekl Linus, je dost irelevantní. Nehledě na to, že Linus jednou mimoděk prohlásí „to jsem ale debil“ a zástup opakovačů od té doby o něm bude říkat, že je debil :D.
21.3.2012 08:10
michich | skóre: 51
| blog: ohrivane_parky
Nehledě na to, že Linus jednou mimoděk prohlásí „to jsem ale debil“ a zástup opakovačů od té doby o něm bude říkat, že je debil :D.Můžou rovnou začít říkat, že Linus je idiot.
Zadej DNS jméno zdroje, který má být dostupný, a uvidíš, že to nebude fungovat.
To je právě tvůj cíl. Já nevidím nic divného na fungování bez DNS, nebo s DNS serverem na jiné lince.
ULA je úplně něco jiného
To je příklad, kdy se mě snažili na fedora-devel přesvědčit, že závěr network manageru o nedostupnosti sítě, kdy je jen ULA adresa, je správný. Je to úplně stejné zjednodušení, jako tady předvádíš s DNS.
Tak to budeš mít docela problém, protože NetworkManager jaksi není specifický pro Gnome
Nejde o desktopové prostřdí. To byla narážka na citát if you think your users are idiots, only idiots will use it
. Network manager má našlápnuto tímto směrem.
To je právě tvůj cíl. Já nevidím nic divného na fungování bez DNSTady se nebavíme o tom, co je mým nebo tvým cílem. Zkus si udělat průzkum mezi lidmi. Normálními, vývojáři, administrátory. Posaď je k počítači, kde je IP kontektivita a není DNS. A polož jim pouze otázku, jestli funguje net.
To je příklad, kdy se mě snažili na fedora-devel přesvědčit, že závěr network manageru o nedostupnosti sítě, kdy je jen ULA adresa, je správný.ULA je přesně opačný příklad. Připojení k ULA s DNS je fungující připojení k intranetu. Tzn, ačkoli to není funkční připojení ke globální síti, je to zcela validní use case pro NetworkManager. Ve spojení s HTTP proxy to dokonce může být plně funkční řešení pro přístup k webu, navíc v praxi často používané.
Je to úplně stejné zjednodušení, jako tady předvádíš s DNS.Chápu. Ty nevidíš rozdíl mezi plně funkčním připojení k intranetu a částečně funkčním připojení internetu. Na tom ale nelze postavit plodnou diskuzi.
Nejde o desktopové prostřdí. To byla narážka na citát "if you think your users are idiots, only idiots will use it".Jako klidně házej vtipnými citáty. Já se budu dál zabývat fakty a tím, co z nich vyplývá.
Network manager má našlápnuto tímto směrem.Pokud za pejorativní slovo idiot dosadíš běžného uživatele, aby vůbec mělo smysl se o tom rozumně bavit... Tak NetworkManager nemá našlápnuto na to stát se programem pro běžné uživatele a případně běžné užití expertem, který zrovna nemá čas si hrát. On jím je. Naopak teďka se hlavní směry vývoje ubírají k tomu, aby byl NM plně použitelný jako serverové řešení, což už je skoro taky, ale pár drobností ještě chybí. A navíc se počítá i s různými bonusovými funkcemi, které jsou jinak dostupné v konfiguraci routerů a to ještě „těch lepších“. NetworkManager je postavený na konceptu jednotlivých připojení. Ta se aktivují, deaktivují, určuje se u nich, zda jsou částečně funkční, plně funkční, atd... A podle mě ti na NM vadí samotný koncept těch připojení a zvláště pak způsob jejich označování za plně funkční, apod. Pokud nejsi schopný tento koncept přijmout, tak existuje jen jediné doporučení: Nepoužívej to a snaž se, abys to používat nemusel. Mně ten koncept vyhovuje včetně toho, že spojení bez DNS nelze považovat za plně zkonfigurované. Co víc, vyhovuje mnohým jiným (i když samozřejmě mnohým ne). A nevidím jediný důvodn NetworkManager přizpůsobovat těm, kterým nebude vyhovovat už z principu. Jediné, co jde pro tyto lidi udělat je hlídat vývojáře aplikací, aby aplikace bez NM fungovaly (například aby nevynucovaly offline mód, když není NM přítomný či aktivovaný). A to jde zajistit prostým hlášením chyb.
A neodpustím si rýpnutí do network manageru. Pokud se mi ztratí nastavení resolveru, tak je to nemilé, ale rozhodně to není konec světa. IP funguje i bez DNS. Takže network manager a ostatní aplikace by se měly podle toho chovat.Nešlo by toto obejít použítím DNS proxy/lokálního cachovácího serveru? Sice nevím, jestli by Network Manager takovouto konfiguraci vzal, ale snad by mu jí bylo možné vnutit nástroji typu
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.3.2012 20:27
resolvconf. Mimo toho, lokalní cachovací DNS má i výhodny ve snížení latence, protože na rychlé lince je čekání na DNS dotaz občas delší, než potom čas potřebný k natažení celé stránky.
PS: Windows tohle dělají také, pokud padne připojení ("Sítový kabel byl odpojen"), pozabíjí všechna otevřená spojení.
Nešlo by toto obejít použítím DNS proxy/lokálního cachovácího serveru?Problém s konfigurací lokálního cachujícího nameserveru je ekvivalentní problém s konfigurací resolv.conf. Lokální nameserver má hlavně výhodu v tom, že umožňuje provozovat DNSSEC aby ta technologie nebyla úplně k hovnu (tedy tak jak se dosud obvykle prezentuje). Plus dejme tomu caching.
20.3.2012 08:25
Jaromír Svoboda | skóre: 9
| blog: netblog
-f, --force-online
Try to be online even if the network is reported (by Windows,
or NetworkManager on Linux) to be unavailable.
Pavlixi jsi dobrej, že to tak rozpitváš. Díky tomu se s tím něco dělá.Já se případně snažím i dodat nějaký patch, jen ze mě ještě nic konkrétního nevypadlo :).
Je možné, že toto chování Pidgina souvisí s popsaným chováním NetworkManageru.Výpadky sítě jsou vždycky protivné. Tím spíš, když link funguje a problém je v samotném konfiguračním protokolu. Jinak jestli tě můžu poprosit, když píšeš do komentářů o chybách, i když takhle nespecifických, odkazuj aspoň dodatečně na bugreport. I kdybys ho měl kvůli tomu založit. Je jedno jestli je to distribuční bugreport nebo upstreamový.