FEL ČVUT vyvinula robotickou stavebnici pro mladé programátory. Stavebnice Brian byla navržená speciálně pro potřeby populární Robosoutěže. Jde ale také o samostatný produkt, který si může koupit každý fanoušek robotiky a programování od 10 let, ideální je i pro střední školy jako výuková pomůcka. Jádro stavebnice tvoří programovatelná řídicí jednotka, kterou vyvinul tým z FEL ČVUT ve spolupráci s průmyslovými partnery. Stavebnici
… více »Ubuntu bude pro testování nových verzí vydávat měsíční snapshoty. Dnes vyšel 1. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Netgate oznámila vydání nové verze 2.8.0 open source firewallové, routovací a VPN platformy pfSense (Wikipedie) postavené na FreeBSD. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 6.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Tor Browser byl povýšen na verzi 14.5.3. Linux na verzi 6.1.140. Další změny v příslušném seznamu.
Člověk odsouzený za obchod s drogami daroval letos ministerstvu spravedlnosti 468 kusů kryptoměny bitcoin, které pak resort v aukcích prodal za skoro miliardu korun. Darováním se zabývá policejní Národní centrála proti organizovanému zločinu (NCOZ). Deníku N to potvrdil přímo ministr spravedlnosti Pavel Blažek (ODS). Podle resortu bylo nicméně vše v souladu s právem.
Svobodný a otevřený multiplatformní editor EPUB souborů Sigil (Wikipedie, GitHub) byl vydán ve verzi 2.5.0. Stejně tak doprovodný vizuální EPUB XHTML editor PageEdit (GitHub).
Na základě národního atribučního procesu vláda České republiky označila Čínskou lidovou republiku za zodpovědnou za škodlivou kybernetickou kampaň proti jedné z neutajovaných komunikačních sítí Ministerstva zahraničních věcí ČR. Tato škodlivá aktivita, která trvala od roku 2022 a zasáhla instituci zařazenou na seznam české kritické infrastruktury, byla provedena kyberšpionážní skupinou APT31, veřejně spojovanou se zpravodajskou službou Ministerstvo státní bezpečnosti (MSS).
Google Chrome 137 byl prohlášen za stabilní. Nejnovější stabilní verze 137.0.7151.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 11 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán AlmaLinux OS 10 s kódovým názvem Purple Lion. Podrobnosti v poznámkách k vydání. Na rozdíl od Red Hat Enterprise Linuxu 10 nadále podporuje x86-64-v2.
Byl vydán Mozilla Firefox 139.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 139 je již k dispozici také na Flathubu a Snapcraftu.
8.6.2011 21:59
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
9.6.2011 20:11
Petr Tomášek | skóre: 39
| blog: Vejšplechty
21.6.2011 17:33
pavlix | skóre: 54
| blog: pavlix
Klídek, takových zpráv nám tu IPv6 šíří deset týdně...Takové zprávy se šíří téměř výhradně po IPv4.
Ale absolutně netuším, jestli je na tom něco pravdy. Nakonec ani autor článku si není jist. Ale vůbec by mě nepřekvapilo, kdyby to byla pravda.
22.6.2011 10:00
egg | skóre: 20
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz:/
21.6.2011 17:35
pavlix | skóre: 54
| blog: pavlix
na AAAA dotaz nevracel zcela nic, tak se cekalo na timeout. Nasleduje AAAA dotaz na jmeno s pridanim vlastni domeny. Dalsi timeout.
Zpet ke vcerejsku. Dokud na DNSkach prakticky zadne IPv6 zaznamy nebyly, byl jsem v pohode.
Ted je vsude nahazeli, IP se vrati a kompu je ... ku nicemu.
Takze jsem opet zcela vykostil podporu IPv6 ze vsech lin kompu aby nedelal AAAA dotazy. Widlaci at si poradi sami.
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 ??? Mozna ano. Mozna se pocita s tim, ze budou mit problemy = budou nasrani. A pak se jen pomuze vseobecnemu povedomi stylem: muze za to vas ISP, pozadujte po nem IPv6 !
9.6.2011 12:21
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
9.6.2011 14:07
Petr Tomášek | skóre: 39
| blog: Vejšplechty
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...
21.6.2011 17:45
pavlix | skóre: 54
| blog: pavlix
9.6.2011 14:36
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
9.6.2011 15:05
AsciiWolf | skóre: 41
| blog: Blog
9.6.2011 15:16
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.
11.6.2011 01:41
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.
21.6.2011 17:49
pavlix | skóre: 54
| blog: pavlix
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.
9.6.2011 20:14
Petr Tomášek | skóre: 39
| blog: Vejšplechty
9.6.2011 22:11
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
21.6.2011 17:59
pavlix | skóre: 54
| blog: pavlix
21.6.2011 17:46
pavlix | skóre: 54
| blog: pavlix
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.
21.6.2011 17:43
pavlix | skóre: 54
| blog: pavlix
$ 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...
9.6.2011 14:37
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.)
21.6.2011 17:39
pavlix | skóre: 54
| blog: pavlix
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í.
9.6.2011 14:12
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
10.6.2011 00:33
Sislik
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 :)
10.6.2011 10:28
contyk | skóre: 3
20.6.2011 14:20
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
To je jako bránit se alternativním pohonům s tím, že až dojde ropa, tak prostě vyrobíme víc benzínu
21.6.2011 18:06
pavlix | skóre: 54
| blog: pavlix
Tohle může napsat jen blázen, který netuší, oč jdeSpíš někdo z místních vtipálků.
19.6.2011 16:01
Petr Tomášek | skóre: 39
| blog: Vejšplechty
21.6.2011 18:04
pavlix | skóre: 54
| blog: pavlix
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
26.6.2011 21:06
pavlix | skóre: 54
| blog: pavlix
26.6.2011 21:25
David Watzke | skóre: 74
| blog: Blog...
| Praha
26.6.2011 21:39
pavlix | skóre: 54
| blog: pavlix
21.6.2011 18:04
pavlix | skóre: 54
| blog: pavlix
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:
