Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Klídek, takových zpráv nám tu IPv6 šíří deset týdně...Takové zprávy se šíří téměř výhradně po IPv4.
:/
mplayer -cache 128 -playlist http://www.rferl.org/realaudio/c12.ram Resolving www.rferl.org for AF_INET6... Couldn't resolve name for AF_INET6: www.rferl.org Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[95.100.248.16]: 80... Cache size set to 128 KBytes MPlayer SVN-********** (C) 2000-2010 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing rtsp://rmlive.rferl.org/encoder/channel12.rm. Resolving rmlive.rferl.org for AF_INET6... Couldn't resolve name for AF_INET6: rmlive.rferl.org Resolving rmlive.rferl.org for AF_INET... Connecting to server rmlive.rferl.org[38.124.238.35]: 554... Cache size set to 128 KBytes Cache fill: 6.25% (8192 bytes)Naopak, dost často to bývá vopruz, dost to zdržuje, když si člověk chce poslechnout třeba zprávy na poslední chvíli... Tohle je ještě dobrý, ale u některých internetových rádií to třeba 5x zkouší různé adresy, než to začne hrát - a pokaždý to 2x resolvuje - a když má člověk to štěstí a je zasekaná linka, tak celkové zpoždění je v řádu sekund...
gethostbyname()
+socket()
(od connect()
dál už je to jedno, protokol se nastavuje jen na začátku) , tak tam se musí protokol nastavit přes AF_INET
/AF_INET6
a PF_INET
/PF_INET6
. Jenže i když je hezké, že getaddrinfo()
pracuje transparentně a aplikace by tudíž mělo být jedno, na jakém protokolu jede, v praxi to zatím bohužel vypadá tak, že existence AAAA záznamu není žádnou zárukou, že se dá s cílem komunikovat přes IPv6. Takže pokud chcete IPv6 podporující aplikaci, tak se stejně prvně musí resolvnou IPv6 adresa, zkusit se připojit, při selhání resolvnou IPv4 adresu a znovu se zkusit připojit a pak teprve se dá prohlásit, že to nejde.
PS: V Linuxu resolvování doopravdy nedělá libc
, ale knihovny NSS, pojmenované libnss_<něco>.so
(file
, dns
, nis
, hesiod
...). To je také důvod, proč libc
není vhodná na dělání statických binárek, protože pokud se použije resolvování, není už ve skutečnosti statická. Takže pokud pášete statické binárky, nepoužívejte libc
, nebo reresolvujte.
Takže pokud chcete IPv6 podporující aplikaci, tak se stejně prvně musí resolvnou IPv6 adresa, zkusit se připojit, při selhání resolvnou IPv4 adresu a znovu se zkusit připojit a pak teprve se dá prohlásit, že to nejde.Správná aplikace si vezme mix záznamů (AAAA+A) a jede od prvního k poslednímu. Pokud na daném PC není IPv6 konektivita, tak pokusy o připojení přes IPv6 adresu selžou velmi rychle. A tohle je korektní postup, i když vás IPv6 nezajímá. Prostě když záznam vrátí více adres, mají se zkusit všechny.
Správná aplikace si vezme mix záznamů (AAAA+A) a jede od prvního k poslednímu. Pokud na daném PC není IPv6 konektivita, tak pokusy o připojení přes IPv6 adresu selžou velmi rychle.Pokud na daném PC není IPv6 konektivita, tak nevím, jeslti getaddrinfo vůbec IPv6 vrací. Ale přinejmenším je to určitě odsune na konec (podle RFC).
Ten, kdo to ví ze všech nejlépe, je manuálová stránka funkce getaddrinfo()
. Vřele doporučuji přečíst si ji důkladně. Jedno volání může vrátit všechny nalezené IPv6 i IPv4 adresy. Aplikace, která pak vznikne, je 100% kompatibilní s IPv4 i IPv6.
Když si aplikace otvírá socket, musí vědět, jakého typu ho chce, zda AF_INET
nebo AF_INET6
. Musí tedy mít jasno v tom, jakou adresu použije. U korektně fungující implementace getaddrinfo()
, například na Solarisu, lze používat pouze a výhradně AF_INET6
sockety, což má tu výhodu, že si člověk může sockety alokovat klidně předem a ušetřit pár mikrosekund latence. V „linuxové“ (glibc) implementaci je už asi deset let tupý bug, který způsobuje, že getaddrinfo()
místo IPv4 adres mapovaných do IPv6 vrací nativní IPv4 adresy. Tedy typ socketu je známý teprve po návratu z getaddrinfo()
. To ale nijak zásadně nevadí a nic to nemění na faktu, že IPv4 i IPv6 adresy se dají resolvovat naráz. To, co vrací getaddrinfo()
, obsahuje dostatek informací pro následný socket()
i connect()
, včetně typu socketu ke každé adrese ve vráceném seznamu.
Pokud aplikace používá nějakou abstrakci (Java, Perl, Qt, ...) záleží na konkrétní implementaci, jak spojení realizuje a jaké parametry přijímá. Tam se to liší případ od případu. Java je IPv6 kompatibilní snad od pravěku, Perl taktéž a pokud jde o Qt ... no, nevím, kdybych to měl posuzovat podle Jabber klienta Psi, možná by Qt potřebovalo řádně vyhubovat.
V „linuxové“ (glibc) implementaci je už asi deset let tupý bug, který způsobuje, že getaddrinfo() místo IPv4 adres mapovaných do IPv6 vrací nativní IPv4 adresy.Na zaklade zbezneho pohledu do RFC 3493 myslim, ze tohle chovani je standardni - getaddrinfo() by mel IPv4 mapovane do IPv6 vracet jen kdyz volajici zada flag AI_V4MAPPED, jinak by mel v takovem pripade vratit nativni IPv4 adresy.
Jenže linuxové getaddrinfo()
se právě podle toho RFC nechová.
Typ požadovaných adres se dá stanovit buď napevno (typ AF_INET
nebo AF_INET6
a žádné AI_*
flagy), nebo bez omezení (typ AF_INET6
a k tomu nastavit AI_ALL
). Ve druhém jmenovaném případě je zcela legitimní vracet IPv4 i IPv6 adresy v seznamu výsledků. Proti tomu nic nenamítám.
Já jsem ale mluvil o případu, kdy nastavím AF_INET6
a k tomu AI_V4MAPPED | AI_ALL
. V tomto případě se mají vracet výhradně adresy typu AF_INET6
, ať už nativní nebo „mapované“. Zatímco na Solarisu tomu tak skutečně je, na Linuxu bohužel nikoliv — stále se vrací také IPv4 adresy, jako by tam AI_V4MAPPED
nebyl.
Jednou jsem se takto spálil, když jsem si v programu, který potřeboval navazovat spousty nových spojení s minimální možnou latencí, alokoval sockety do zásoby v odděleném vlákně. To se dá dělat za předpokladu, že dopředu znám protokol, tedy AF_INET6
. Jenže na Linuxu to selhávalo právě proto, že některé z vracených adres byly typu AF_INET
, přestože flag AI_V4MAPPED
byl nastavený.
Toto se ovšem týká situace před cca 4 měsíci. Třeba už to (konečně) někdo opravil. Ta chyba tam je (byla?) minimálně několik let, pokud si pamatuju.
Sorry, ale tohle je blbost MPlayeru. Normální aplikace resolvuje AF_INET a AF_INET6 najednou. Posílat požadavek dvakrát je nesmysl.Petr Tomášek jaksi zapomněl zmínit, že zvolil něco, co zřejmě nefunguje ani po IPv4.
To je ale problém jednoho konkrétního zmršeného programu. Kdyby mplayer používal standardním způsobem getaddrinfo()
, pravděpodobně by takové ptákoviny nedělal.
Neexistuje žádný důvod resolvovat odděleně IPv4 a IPv6. Flagy AF_INET6
, AI_V4MAPPED
a AI_ALL
u getaddrinfo()
jsou opravdu znamenitá věc. Zajistí 100% zpětnou kompatibilitu s IPv4 (bez prodlev, je-li getaddrinfo()
implementováno korektně). A jestli se bude nebo nebude preferovat IPv6, to už záleží výhradně na /etc/gai.conf
; samotná aplikace (binárka) může zůstat beze změn.
$ mplayer -prefer-ipv4 -cache 128 -playlist http://www.rferl.org/realaudio/c12.ram Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Cache size set to 128 KBytes Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET... Connecting to server www.rferl.org[92.123.68.50]: 80... Resolving www.rferl.org for AF_INET...
Tak to je skvělá motivace dát si do pořádku DNS server, že ano. IPv6 day je důležitý právě proto, aby tyhle nefunkční DNS servery odhalil.
Dnešní systémy upřednostňují IPv6 tehdy a jen tehdy, pokud mají nakonfigurovanou veřejnou IPv6 adresu a default route (::/0) aspoň na jednom rozhraní. V opačném případě o žádném upřednostňování nemůže být řeč. Má-li systém jen IPv4 adresy, bude používat jen IPv4. (Jakákoliv jiná situace znamená, že je něco zásadně špatně nastaveno, případně že by ten systém měl někdo vyhodit oknem.)
Ja teda ANO ... tolik nenalezenych jmen jsem jeste nevidel.Nenalezených jmen? Jako že někdo někde odebral nějaký záznam? Jestli ano, napiš jeho šéfovi a on už si to s ním vyřídí.
To hypovani je asi potrebne, ale zamyslel se nekdo nad tim, co to udela s tou spoustou lidi s IPv6 podporou v OS ale s IPv4 only konektivitou ???Lidé, kteřé mají jen a pouze IPv4, žádné problémy se zapnutím IPv6 na daných službách nepocítili.
Kdysi jsem musel tu podporu ze systemu vymlatit, protoze DNS jednoho velkeho nejmenovaneho ISPTo je chyba implementace resolveru, že se ptal na AAAA s přidanou doménou dříve než na A bez ní.na AAAA dotaz nevracel zcela nic, tak se cekalo na timeout. Nasleduje AAAA dotaz na jmeno s pridanim vlastni domeny. Dalsi timeout.
jojo, jak v praci, tak doma a vsude mam IPv6 nativne (tj. bez potreby tunelu)
pri praci jsem na zadnej problem vubec nenarazil
doma jsem narazil akorat na problem se servery internet infa (krome roota a jsem si jistej, ze chyba byla na jejich strane), jinak vsechno slapalo jako hodinky a treba youtube mi prislo subjektivne nejaky rychlejsi po v6, mozna nekde nezafungoval QoS :)
doma jsem teda akorat musel nastavit jinou DNS, protoze DNS, co dostanu od DHCP preklada jen minimum adres na IPv6 (ale to je jinej problem), ale driv to fungovalo, nevim co s tim je, ale ono je to skoro jedno, jediny, na co IPv6 prakticky pouzivam, je RDP z domova do prace, ze nemusim vytacet VPN :) jinak to pro me zadnej valnej vyznam nema...
"vtipny" bylo zakazat na sitovce IPv4 a mit jenom IPv6 sit, Win7 s tim sice vubec problem nemaji, ale jinak skoro nic neslo :D sice jsem si vygooglil cokoliv, jenze nalezeny vysledky nemely v6 adresy :) a tak :)
Tohle může napsat jen blázen, který netuší, oč jdeSpíš někdo z místních vtipálků.
a co tak napriklad vyskusat vyssie cisla v IP, az sa mi nechce verit ze to doteraz nikdo nevyskusal,napr. ip by bola 684.953.700.** ...jak jedonuche zvysit aspon prve trojcislie od 300 az do 900 a mame tu milionove moznosti :):)Jojooo, ten taky znám! :D
som zrejme jeden z velmi mala, alebo dokonca jediny uzivatel linuxu ktoremu sa IPV6 nepaci a nechcem ju, je odpuzdujuca...Jediný nejsi, ale je vám to prd platné.
Tiskni
Sdílej: