GHC (Glasgow Haskell Compiler, Wikipedie), tj. překladač funkcionálního programovacího jazyka Haskell (Wikipedie), byl vydán ve verzi 9.10.1. Přehled novinek v poznámkách k vydání.
Po 9 týdnech vývoje od vydání Linuxu 6.8 oznámil Linus Torvalds vydání Linuxu 6.9. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.
Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Je to tím, že některé programy respektují řádku hosts:
v /etc/nsswitch.conf
a některé ne. Pokud používají getaddrinfo()
ze standardní knihovny (což je s největší pravděpodobností případ command-line utilit), resolving funguje podle nsswitch.conf
. Pokud naopak mají nějaký svůj vlastní resolving (což je u prohlížečů docela časté), může se klidně stát, že používají výhradně DNS a /etc/hosts
vůbec neřeší. (Často uváděným pseudodůvodem bývá, že /etc/hosts
je (údajně) neportovatelná záležitost, protože jeden jediný divný nekompatibilní systém takový soubor nemá.) Dá se to vyřešit například pomocí dnsmasq
, který se dá nastavit tak, aby bral ohled na /etc/hosts
. (Přesněji řečeno, implicitně tak dokonce nastavený je, jen člověk nesmí mít jistou z[cenzurovanou] distribuci, která nastavení dnsmasq z[cenzuruje].)
Tohle je fakt divné. Není v tom browseru nějaká (vnitrofiremní nebo kdovíkterá jiná) proxy konfigurace, která by třeba přidávala custom TLD nebo nějak resolving měnila? Tady jsou nějaké staré řeči o tom, jak je to v Chromiu s getaddrinfo()
, proč ano a proč ne a tak podobně, ale nejsem z toho příliš moudrý, jestli by to pasovalo na tento případ.
Čistě pro úplnost dodám, že existuje příkaz getaddrinfo
, který volá funkci getaddrinfo()
. Ten minitool je v balíku perl-socket-getaddrinfo
či v jeho ekvivalentu pro jiné distribuce. Tím se dá zjistit, co a kdy přesně getaddrinfo()
vrací, kolik toho je atd. atp. Ale tady to asi (určitě) nepomáhá, protože jestli tomu dobře rozumím, tak getaddrinfo()
dělá správnou věc a jenom resolving v browseru nefunguje.
jeden jediný divný nekompatibilní systém takový soubor nemáKterý? Windows takový soubor mají, dokonce se jmenuje
hosts
a je v adresáři etc
(historie síťového stacku Windows je spletitá).
Často uváděným pseudodůvodem bývá, že /etc/hosts je (údajně) neportovatelná záležitost, protože jeden jediný divný nekompatibilní systém takový soubor nemá.
To nějak nedává smysl. Smyslem getaddrinfo()
(nebo gethostbyname()
) je právě to, aby se program vůbec nemusel zabývat tím, že (ne)existuje nějaký /etc/hosts
a/nebo nějaké DNS dotazy a jestli třeba daný systém místo nich nepoužívá k resolvování jmen třeba LDAP nebo SQL databázi. Takže ručně zadrátovaný DNS resolver by portabilitu naopak snižoval.
Nevím, proč browsery nepoužívají standardní getaddrinfo()
. Dívají se sice třeba do /etc/gai.conf
i do několika dalších klasických konfiguráků, ale jejich chování se od implicitního getaddrinfo()
prostě liší. A ano, naprosto souhlasím s tvrzením, že něco takového nedává smysl.
přestane mi fungovat v prohlížečích resolvingTo jste nějak ověřil a víte to, nebo je to jen domněnka? Nemůže problém způsobovat ověřování názvu na blacklistech, validace DNSSEC v pluginu nebo něco jiného?
výsledek je prostě, že nefunguje name-resolvingNa to jsem se právě ptal, jak tohle víte. Prohlížeč vám asi nevypíše chybu „prostě nefunguje name-resolving“. A i kdyby ji vypsal, je rozdíl v tom, zda ji vypíše hned, nebo až po vypršení nějakého timeoutu. Kdybyste popsal, co se doopravdy děje, bude hledání příčiny mnohem snazší. Třeba: „Zadám do adresního řádku adresu, kterou prohlížeč nemá nakešovanou, a hned se obrazí chyba 'ABC'.“ Nebo „…, prohlížeč cca 30 dnů točí kolečkem a pak se zobrazí chyba 'EFG'.“
koneckonců taková validace by stejně u "lokálních" jmen selhalaJenže je podstatný rozdíl mezi tím, když prohlížeč hned dostane odpověď „neznám“, než když bude marně čekat na odpověď, dokud to nevzdá.
Tiskni Sdílej: