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).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.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 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Tiskni
Sdílej:
28.5.2012 16:50
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Myslim, ze to vidis zbytecne cerne. Me prevazna vetsina IPv6 veci v systemu funguje bez potizi a prakticky stejne jako na IPv4.Nevidím to černě :). Máme už opravy pro všechny problémy, které brání běžnému provozu IPv6-only stanice. Jen ještě nejsou všechny ani v upstreamovém Gitu, a počítám, že to během nejbližších měsíců proteče přes upstream alespoň do Fedory.
Jak je na tom NetworkManager to netusim (nepouzivam), nicmene podle ruznych komentaru to vypada na pekne obsurni kus software, ktery byl nasazovan vyrazne drive, nez vubec splnoval zakladni pozadavky na IPv4, takze ze podobna situace je u IPv6 by me ani neprekvapilo.Bez userspace démona nelze na Linuxu vůbec konfigurovat DNS. Kernel nemůže zasahovat do
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.5.2012 17:41
/etc/resolv.conf ani jinak předávat informace o DNS místnímu resolveru. Pokud na IPv6-only síti nepoužíváš NetworkManager, musíš používat nějakou jinou alternativu. Výjimkou jsou staticky konfigurované DNS.
Co se tyce DNS v RA, tam zaspalo hlavne IETF, kdyz to standardizovali az pred par lety. To tedy v Linuxu bezne nefunguje, nicmene to neni zas tak duleziteTen standard už má druhou iteraci. Navíc ten standard je napsaný s předpokladem, že se neztrácejí pakety. Co víc, on je napsaný s předpokladem, že se neztrácejí multicastové pakety. Na multicastu na wifi jsme docela slušně pohořeli i s IPv4 OSPF. RFC 6106 je třeba opravit, aby fungovalo i na něčem jiném než 100% spolehlivých sítích.
(malokdo hned pocita s IPv6-only rezimem, takze DNS pres IPv4 je prijatelny kompromis).Právěže mnoho firem a případně i ISP z mého okolí nechce o dualstacku ani slyšet a mnohem spíše by šli do IPv6-only režimu s NAT64 a DNS64. Tím se zbaví potřeby spravovat duální síť. V tomto směru tedy přijetí IPv4 DNS jako kompromisu jde přímo proti spuštění IPv6, natož světovému. Bavíme se samozřejmě o klientské straně, na serverech je dualstack přirozeným řešením. Naštěstí RDNSS funguje a DHCPv6 Information Request taky.
DHCPv6 jsem nezkousel, na IPv6 si plne vystacim s RA.Ne všichni chtějí nechat přidělení adres na klientských stanicích. Řízená konfigurace adres je pro mnoho provozovatelů sítí důležitá a bez ní do IPv6 nepůjdou. Na dualstacku se navíc selhání IPv6 konfigurace může projevit sestřelením celého rozhraní včetně IPv4. Mimochodem, DHCPv6 Prefix Delegation je killer feature pro centrálně řízenou konfiguraci sítě většího rozsahu. Můžeš tak naadresovat celou síť z jednoho serveru napojeného na jednu databázi (replikovanou kvůli redundanci).
Bez userspace démona nelze na Linuxu vůbec konfigurovat DNS. Kernel nemůže zasahovat do /etc/resolv.conf ani jinak předávat informace o DNS místnímu resolveru. Pokud na IPv6-only síti nepoužíváš NetworkManager, musíš používat nějakou jinou alternativu. Výjimkou jsou staticky konfigurované DNS.No, proto jsem taky psal, ze (mi) DNS z RA nechodi. Prirozene by asi bylo rovnou fixnout ten resolver v libc, aby si mohl brat konfiguraci primo z jadra.
Navíc ten standard je napsaný s předpokladem, že se neztrácejí pakety. Co víc, on je napsaný s předpokladem, že se neztrácejí multicastové pakety. Na multicastu na wifi jsme docela slušně pohořeli i s IPv4 OSPF.A nestaci proste nastavit parametry tak, aby se RA posilaly vyrazne casteji? Odobne s OSPF, to pouzivam na wifi s hello 5 a dead 60 a vcelku bez potizi. Jinak, pokud jsou potize se ztracejimi se pakety, tak ten problem ma cele RA, ne jenom RFC 6106, ne?
No, proto jsem taky psal, ze (mi) DNS z RA nechodi. Prirozene by asi bylo rovnou fixnout ten resolver v libc, aby si mohl brat konfiguraci primo z jadra.To by bylo přirozené, a zrušení resolv.conf a převedení seznamu nameserverů do kernelu bych uvítal. Ale je to obrovská změna, která by se týkala všeho možného bez ohledu na IPv6 či IPv4. Dotkla by se i možnosti používat lokální resolver místo toho ze seznamu (při zachování seznamu). To by ovlivnilo i novinky jako třeba DNSSEC v podobě v jaké je dostupný ve Fedoře 17.
A nestaci proste nastavit parametry tak, aby se RA posilaly vyrazne casteji? Odobne s OSPF, to pouzivam na wifi s hello 5 a dead 60 a vcelku bez potizi.Jasně, dead interval se dá zvyšovat, ale to zase zhoršuje reakci sítě na skutečný výpadek. Navíc to není jenom wifi, jsou to i některé switche. A může se ti stát, že máš takovou smůlu, že se ti ty špatné prvky sejdou pohromadě. NBMA to jistí.
Jinak, pokud jsou potize se ztracejimi se pakety, tak ten problem ma cele RA, ne jenom RFC 6106, ne?Ty problémy se opravdu objevují i mimo RFC 6106, ale zcela minimálně. RFC 6106 speciálně nastavuje parametry tak, že to srovnání s OSPF opravdu nesnese. Zatímco default OSPF je čtyřnásobek, ty sám píšeš, že používáš dvanácti násobek, tak RFC 6106 explicitně specifikuje jednonásobek jako spodní hranici a dvojnásobek jako horní. Doporučuju překousnot to, že je to XML nebo si ho nechat převést na některý RFC formát a přečíst si ten odkazovaný rozpracovaný dokument. Budu rád za každý nápad a komentář k tomu, co je tam popsáno.
The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at least 5*MaxRtrAdvInterval so that there are enough Router Advertisements recieved by the host to avoid this. When the administrator sets a lower value, the system SHOULD issue a warning.Tohle me prijde jako overkill. Vzhledem k tomu, ze nejdulezitejsi lifetime AdvDefaultLifetime je defaultne 3*MaxRtrAdvInterval a RFC 4861 nespecifikuje zadne warningy pro nizsi hodnotu, prijde mne rozumne, aby AdvRDNSSLifetime a AdvDNSSLLifetime bylo handlovano naprosto stejne.
Use Router Solicitations as a last resortTo mne prijde vcelku zbytecne.
Use DNS even after LifetimeTo mne naopak prijde jako pomerne smysluplne reseni, i kdyz pokud vyprsi default routa, tak uz to je vcelku stejne jedno, a pokud nevyprsi, tak rouzmna hodnota AdvRDNSSLifetime a AdvDNSSLLifetime zajisti nevyprseni DNS, takze to je taky vcelku zbytecne.
Hosts with automatically configured DNS SHOULD use DNS servers provided by the current local network (RA or DHCPv6). It MUST NOT use servers automatically configured in other networks.Tohle je dobry a smysluplny postreh, nicmene ta formulace je priserna - ty DNS servery nemusi byt 'provided by the current local network' (mohou byt nekolik hopu dal), ale spis jde o to, ze by mely byt pouzity ty DNS servery, ktere jsou konzistentni s aktualne pouzivanou konfiguraci site (napr. byly doporuceny skrz RA od stejneho routeru, ktery slouzi jako default gw).
Tohle me prijde jako overkill. Vzhledem k tomu, ze nejdulezitejsi lifetime AdvDefaultLifetime je defaultne 3*MaxRtrAdvInterval a RFC 4861 nespecifikuje zadne warningy pro nizsi hodnotu, prijde mne rozumne, aby AdvRDNSSLifetime a AdvDNSSLLifetime bylo handlovano naprosto stejne.Díky za názor, všechno v tom textu je třeba brát jen jako sebrané nápady, ne finální podobu. Tohle je v podstatě opsáno z jednoho z mých prvních mailů na IETF, ještě než jsem se celou věcí stihl probrat.
Tohle je dobry a smysluplny postreh, nicmene ta formulace je priserna - ty DNS servery nemusi byt 'provided by the current local network' (mohou byt nekolik hopu dal), ale spis jde o to, ze by mely byt pouzity ty DNS servery, ktere jsou konzistentni s aktualne pouzivanou konfiguraci site (napr. byly doporuceny skrz RA od stejneho routeru, ktery slouzi jako default gw).Jo, to bude nejspíš formulace od Fernanda Gonta. On ten text začal psát původně, než mi nabídl se na tom účastnit. Já teda doufám, že se brzo objeví, on je nejspíš někde na dovolené či co. Až se to trochu prodiskutuje, tak si stejně myslím, že to získá úplně jinou podobu než je ta současná.
Mimochodem, DHCPv6 Prefix Delegation ...BTW, netusis, jaky je stav s podporou prefix delegation ve stavajicim software? Napr. Linuxove DHCP servery? To primo vytvareji routy do kernelu, nebo nejak komunikuji s routovacim software? A jak to funguje na ADSL ci jinych linkach fungujicich pres PPP, tam se taky pouziva DHCPv6, nebo se to konfiguruje pres PPP, jako autokonfigurace na IPv4? Premyslim, co nasadit ve wifi sitich jako klientske krabicky s podporou IPv6. Dost pochybuju, ze nejake takove bez potizi fungujici (zvladajici napr. autokonfiguraci s prefix delegation) se bezne prodavaji. Takze zatim spis uvazuju o semistaticke konfiguraci v kombinaci s RIP - prefix rucne nastaven v krabicce, ta ho pres RA propaguje na downstream (LAN) interface a pres RIP ho propaguje na upstream (WAN), kde ho RIP demon prijme a nastavi routu.
BTW, netusis, jaky je stav s podporou prefix delegation ve stavajicim software? Napr. Linuxove DHCP servery? To primo vytvareji routy do kernelu, nebo nejak komunikuji s routovacim software?ISC DHCP by to mělo umět, ale zatím jsem neměl čas to nějak více testovat.
A jak to funguje na ADSL ci jinych linkach fungujicich pres PPP, tam se taky pouziva DHCPv6, nebo se to konfiguruje pres PPP, jako autokonfigurace na IPv4?Pokud vím, tak se PPP by se mělo umět nějak kombinovat s DHCPv6 a nebo přidělovat rovnou jako u IPv4. Nepracoval jsem s tím, ale něco málo se řeší právě v NetworkManageru.
prefix rucne nastaven v krabicce, ta ho pres RA propaguje na downstream (LAN) interface a pres RIP ho propaguje na upstream (WAN), kde ho RIP demon prijme a nastavi routu.Jojo, to chápu, v malém měřítku bych šel do toho samého.
rdnssd taky budu muset testnout aspoň pro zajímavost.
28.5.2012 17:44
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Neviděl bych to tak černě. Jestli něco neumí NetworkManager, no tak se to prostě časem dodělá.Vždyť jsem jen napsal, že to nestihneme do šestého června tohoto roku. Nic víc, nic míň :).
A že se na to ISP vysrali?To jsem nepsal.
Takže se na to těším (obzvláště na oběd) a možná bychom mohli vypnout všechny IPv4 only servery, ať máme 100% v6!+1 Škoda, žádné IPv4-only servery nevlastním a neprovozuju, takže je nemůžu ani vypnout.
28.5.2012 19:43
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
To jsem nepsal.
Ale já jo
Škoda, žádné IPv4-only servery nevlastním a neprovozuju, takže je nemůžu ani vypnout.
Se musí chlubit. 
Když ono je to při počtech několika set webů poněkud složitější. Ale LE už jede na šestce něco přes rok a půl (ani nevím, jestli jsme z velké trojky ABC, Root, LE nebyli první, nejspíš to bylo abc), po linuxáře je to tedy dobré.
Jinak opravdu maximálním možný způsobem naléhejte na své poskytovatele připojení a tam, kde to ještě není i na poskytovatele hostingových služeb. Na tomhle pomalém přechodu je jednou z nejhorších věcí (pro mě) fakt, že si stále více lidí a techniků zvyká na to, že jediné správné a bezpečné připojení je přes NAT. A vy poskytovatelé, vypněte maškary a adresujte.
Ale já joTi, se kterými spolupracuju, IPv6 v síti mají a na požádání ho i přidělují. Ale to není World IPv6 Launch, že.
Když ono je to při počtech několika set webů poněkud složitější.Mě to z pohledu hostingu přijde stejně jednoduché jako u jednoho webu. Prostě ke každé IPv4 adrese přijde jedna IPv6, ideálně podle nějakého deterministického mapování. To je spíš horší řešit to, že aplikace někdy pracují s IP adresami.
Když ono je to při počtech několika set webů poněkud složitější. Ale LE už jede na šestce něco přes rok a půl (ani nevím, jestli jsme z velké trojky ABC, Root, LE nebyli první, nejspíš to bylo abc), po linuxáře je to tedy dobré.Měl jsem pocit, že iinfo to zvládlo dřív, ale jistý si nejsem. Ještě tu chybí single sign on v podobě OpenID :).
Jinak opravdu maximálním možný způsobem naléhejte na své poskytovatele připojení a tam, kde to ještě není i na poskytovatele hostingových služeb.U poskytovatele připojení jsem IPv6 konfiguroval vlastníma rukama. V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).
Na tomhle pomalém přechodu je jednou z nejhorších věcí (pro mě) fakt, že si stále více lidí a techniků zvyká na to, že jediné správné a bezpečné připojení je přes NAT.Tohle řeším na úrovni školení a přednášek. Lameřiny typu používání maškarády jako bezpečnostní techniky se snažím předcházet už v začátku.
28.5.2012 20:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Prostě ke každé IPv4 adrese přijde jedna IPv6, ideálně podle nějakého deterministického mapování.
V přiřazení adrese serveru opravdu problém není, že ano. 
Tím práce začíná, je třeba přidat dns záznamy (ne všechny spravujeme), je třeba mít podporu v app apod. Jde to, ale je to pomalý proces. Pomalejší, než jsem si na počátku představoval. Ono už jen třeba dřívější přeadresování na vlastní subnet ipv4 se vleklo právě k vůli pomalým externím správcům dns.
To je spíš horší řešit to, že aplikace někdy pracují s IP adresami.
single sign on v podobě OpenID
Z toho tedy tak odvázaný nejsem. Měl jsem na vlastním serveru vlastního poskytovatele idenity (nebo jak se to jmenuje), na těch pár serverech, což OpenID umějí, jsem to používal a nějak jsem nepoznal rozdíl. Stejně si tam člověk musí vytvořit účet, který jen spáruje s OpenID. Hmm. To už by se mi líbilo (ale to by dost lidí prskalo z hlediska anonymity), mít automatické přihlašování a vytvoření účtu při první návštěvě pomocí klientského certifikátu v prohlížeči.
U poskytovatele připojení jsem IPv6 konfiguroval vlastníma rukama.
Nápodobně.
V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).
Souhlas, asi bych musel hodně dlouho přemýšlet, jestli jsem vůbec někde zavadil o hosting bez šestky.
Tohle řeším na úrovni školení a přednášek. Lameřiny typu používání maškarády jako bezpečnostní techniky se snažím předcházet už v začátku.
A díky ti za to.
Není třeba chodit daleko. (Pravda, je to trošku zanedbané, v létě to budu dohánět.)V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).Souhlas, asi bych musel hodně dlouho přemýšlet, jestli jsem vůbec někde zavadil o hosting bez šestky.
V přiřazení adrese serveru opravdu problém není, že ano.Tak to řeknu, že jde o záznamy na cizích DNS serverech :). Musím se přiznat, že ty taky řeším laxně. Zákazník, který nechá veškerou správi „na nás“ (tedy na mém zákazníkovi, provozovateli služby), má prostě určitou výhodu.
To už by se mi líbilo (ale to by dost lidí prskalo z hlediska anonymity), mít automatické přihlašování a vytvoření účtu při první návštěvě pomocí klientského certifikátu v prohlížeči.To bych považoval za další stupeň SSO, který má své výhody i nevýhody.
A díky ti za to.Zpravidla si za to nechávám děkovat na účet :). Ale je fakt, že naposled jsem se zákazníky při velkém zájmu zůstal do sedmi do večera, akorát jsme se museli přesunout do KFC ke stolu u zásuvky. Škoda, že nemáme fotku, na stole rozložené tři notebooky, nějaká deska od Mikrotika a kabeláž.
29.5.2012 00:49
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Měl jsem pocit, že iinfo to zvládlo dřív, ale jistý si nejsem.Root jako takový byl přes IPv6 přístupný docela brzo, ale stylospis a obrázky to tahalo z nějakého jiného serveru, který IPv6 neměl.
*) nebo spíš zablokovat na firewallu, ať se nemusejí restartovat démoni
Nevíte někdo víc informací o UPC versus IPv6? Na jejich stránkách je jenom toto: Obecné prohlášení + otázky a odpovědi ohledně IPv6.
Díky za info. Já Internet od UPC mám a to z toho důvodu, že u nás de facto nic jiného nepřipadá v úvahu.
Kutná Hora
Bohužel KH net nemůžu použít.
Případně emailem, ať to tu nesviníme ... jsem k nalezení na pár kliků.
Není nikdo dostatečně blízko, abych se přes něj kabelem (ethernet) připojil. O bezdrátové připojení nemám zájem.
O bezdrátové připojení nemám zájem.Chyba.
Moje jediná praktická zkušenost s bezdrátovým Internetem je Internet mého šváry na vesnici. Tam když se připojí víc lidí současně, tak rychlost (download) jde "do háje" takovým způsobem, že např. wwww.seznam.cz aj. se načítá neúměrně dlouho.
Momentálně mám Internet od UPC (dowload až 60 Mb/s, upload až 6 Mb/s) a vlastně (zatím) jediné, co mi na něm vadí, je, že o zavedení IPv6 (zdá se) zatím pouze píšou. Chtěl bych jednu nebo víc veřejných IPv6 adres, ale zatím mám houby.
, což je ale furt víc než UPC. Ono taky záleží na tom, jakou značku párků má rád Tvůj poskytovatel
Pochlub se, kolik platíš.
Moje jediná praktická zkušenost s bezdrátovým Internetem je Internet mého šváry na vesnici. Tam když se připojí víc lidí současně, tak rychlost (download) jde "do háje" takovým způsobem, že např. wwww.seznam.cz aj. se načítá neúměrně dlouho.Moje praktická zkušenost s bezdrátem je zcela bezproblémová přípojka, která zvládá v součtu cca 70 mbit max, latence naprázdno je do 3 ms. IMO tvé zdůvodnění je něco jako kdybych už nikdy nechtěl drát, protože jsem měl jednou drát přestřižený. Ale každému, co jeho jest. Mně osobně vyhovuje, když je provozovateli sítě možné zavolat a třeba ho i potkat osobně.
Díky. Popřemýšlím o tom.
dovolte, abychom reagovali na Váš e-mail ze dne 31. 5. 2012. Náš DHCP server zatím nepřiděluje IP adresy IPv6. Budete ale s velikým předstihem kontaktován v budoucnu. Děkujeme. V případě, že budete reagovat na tento e-mail, využijte prosím opět standardního formuláře, který naleznete na http://web.upc.cz/klpoz/cz/ S pozdravem a přáním příjemného dne Tomáš Lejčko Specialista technické podpory datových služeb UPC UPC Česká republika, s.r.o.Tzn, zda se ze uz ani o nadsence a "testery" nemaji zajem jak tvrdili ve vyjadreni k IPv6 Launch :( Karel Peran - Nunak
28.5.2012 19:47
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
29.5.2012 08:27
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Na šestce mají restriktivnější firewall:
nmap scan report for 2001:af0:ffee:200::c2d5:2917 Host is up. PORT STATE SERVICE 80/tcp filtered http 443/tcp filtered https
Nmap scan report for www.justice.cz (194.213.41.145) Host is up (0.010s latency). PORT STATE SERVICE 80/tcp open http 443/tcp filtered https
tak k cemu ty ipv6 adresy vubec maji...Tohle je problém dualstack světa. Lidé jsou zvyklí funkčnost webu testovat tím, že se na něj podívají. To zvládne každý. Otestovat jednotlivě IPv4 a IPv6 už ne. Zvykej si, už teďka se ti může stát stejná věc u IPv4, když se na stránky budou lidé dívat z organizace, kde IPv6 je a nenapadne je testovat IPv4.
29.5.2012 11:27
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
29.5.2012 20:25
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Mají tam pravděpodobně MTU problém. Tzn. pokud doma máte šestku přes tunel, nebo váš ISP v cestě používá MTU<1500, tak vám nebude fungovat Justice ani tamní rejstřík. A nepomáhá ani úprava MSS (což třeba u o2.cz zabralo) Z firemního nativního připojení s MTU=1500 není problém.Není to způsobené takovými těmi experty, co zakážou ICMP, takže pak nechodí pakety o překročení MTU?
28.5.2012 23:46
28.5.2012 18:17