Příspěvky

1771

O serveru Root.cz / Celostránková reklama překrývající obsah

« kdy: 11. 07. 2020, 09:56:03 »

V posledních dnech se mi na diskusním fóru opakovaně zobrazuje celostránková reklama, která překryje celý obsah stránky – nad ní jsou jen další reklamy a menu Roota. Bylo to víc různých reklam, ale určitě opakovaně jedna reklama PPL (viz přílohu), která vede na následující URL: https://track.adform.net/C/?bn=38189747;crtbwp=SenO-mKUkTKJJKQk7GaWnWGZM81epO-d0;crtbdata=MyTr_yyz7nnq9rq4mugZW-KTWzbKb3R-wUxe4q6I5uI4wRbKnZslWkLJHEcGiM8x-ls5vqSr0V3tmVH44-Im3emnpKSDYyw4fMK28SuGJRL4b57WYE3k8KOQtXBvBddNVBnsTQZfnA7Z1nLX8GRAyHp3V6bH4iMXgiXX2mBBc9bX678U8yKPGJlHwbeJBXfCOJrN-3bK6xDXnwfafjWBB4tXScCLv92x79Pacmcrew1Z_VQbMRaZJ41Mrxuo0LUkhSKOurXPB3eMI7x8bnq-h7iRCSRYKsFNaW_KCqghOR1XVZPws24isU1jS77_1FR0cQkuGCTWkCD3Kak4dtae1iTGnWevm8T_uD5_thA2mAf_Z9qwbVs4y6rTd8FDRN7gNqM6vjHHzrGpEUO-iqlUpoPtxaT25nMKV4oH0iUmW93Q1GxNQ0MlQUCjUMKFKMwpnABG-RjorFWfuEtE2hF-AWobmSaKt4W6qpTPICb25XjWaUjPx3SqVw2;ccsid=131868;adfibeg=0;cdata=nMYolybY4XbAt4kdwzaLcqG6ThyLTPl8qiV-f6JHXKhtyVSkwp9oeQRPL0hxxa5gvsXjCTniHV2RatnvxH5Y0q8F_tX29Nr_CY3qQ4sp-l6-tyhOiFKNID1VNLdjX7dUVE47BkxPN4SHRM3Sg7_yiSTxSiRXXDizcR5JEzOKsnrk2Rij8wxKfNO8fzh5_-FM0OaiDHTaMZRNv63E28s82KmmvJOXHqcQYjJtwIHKv-hireBfynLJY_UCDfiyzoQhNlXAHkBKS1IsbYshI-_-qqBZIidRWYqvmQZFEQbOLQZQW0dvmv3wi2iftnw3W-EQPqqNd11OG8FLggzqdiM7BtM5tFAboIpxrhasITyi8afWWqnQrckEdQ2;;CREFURL=https%3a%2f%2fforum.root.cz%2findex.php%3ftopic%3d23246.msg333070%3btopicseen

1772

Sítě / Re:WhatsApp na WiFi a problem se slysitelnosti

« kdy: 10. 07. 2020, 19:06:07 »

Nevim, myslite, ze ma smysl vnucovat pomoci DHCP WiFi klientum mensi MTU? Prijde mi to jako dost velky hazard - buh vi, jak to bude s akceptaci takove optiony napric platformami.

Pochopil jsem to tak, že není slyšet zvuk, který jde z venku do vaší sítě, takže myslel spíš jestli vám z venku nepřicházejí příliš velké pakety, které by se někde u vás v síti ztratily nebo poškodily. Takže klientům bych asi menší MTU nenastavoval.

Ale myslel jsem si, že WhatsApp používá pro volání nějaký UDP protokol. Podle těch požadavků to evidentně tunelují přes HTTPS, takže kdyby byl nějaký problém s pakety, rozpadlo by se celé TCP spojení, což by aplikace nějak ohlásila a hlavně by nešel zvuk ani jedním směrem. Leda že by WhatsApp používal dvě spojení, jedno pro příjem hlasu a druhé pro odesílání. Ale to by se mělo dát docela snadno zjistit ze síťového provozu.

Pokud je to opravdu jen jedno spojení a není slyšet jen jedna strana, zatímco druhá strana slyšet je, znamená to, že spojení je v pořádku – ale pravděpodobně se aplikace rozhodne, že už zvuk raději nepřehraje. K tomu by mohlo docházet, pokud by vyhodnotila, že některé část mají velké zpoždění a zadrhávalo by se to. Třeba pokud by se pakety nějak bufferovaly a pak odeslaly ve větší dávce. To by asi chtělo zjistit, jak ta komunikace WhatsAppu vypadá (zda je to opravdu jen jedno spojení), a pak ideálně nějaké takové vadné spojení zaznamenat a pak analyzovat, jestli tam nebude něco divného.

1773

Sítě / Re:WhatsApp na WiFi a problem se slysitelnosti

« kdy: 10. 07. 2020, 17:22:44 »

Nezkoušeli jste, zda není problém s MTU?

1774

Windows a jiné systémy / Re:Umístění aplikace na Google Play / Apple store

« kdy: 10. 07. 2020, 14:23:18 »

Ona z principu klasická webová stránka stačí, ale problém je v tom, že cílové skupině zákazníků (manažeři) jim je zatěžko zadávat adresu do prohlížeče nebo si dělat záložku. Majitelé tedy chtějí, aby si stáhli aplikaci, která jim přidá do telefonu ikonu ke spuštění.

PWA můžete umístit do Google Play, do Apple Store je to trochu složitější.

1775

Windows a jiné systémy / Re:Umístění aplikace na Google Play / Apple store

« kdy: 10. 07. 2020, 09:42:07 »

Podle mne s tím u Apple můžete mít problém.

Proč chcete vytvářet tu aplikaci, když nebude oproti webu přinášet nic navíc? Já radši použiju web než abych si instaloval další aplikaci, která nemá žádnou přidanou hodnotu. Na Androidu by myslím i mělo jít vytvořit odkaz na web, který se bude tvářit jako tlačítko aplikace, na iPhonu to podle mne půjde také (vzhledem k tomu, že se kvůli tomu do HTML vkládají odkazy na speciální ikonky).

1776

Sítě / Re:Pripojeni se na IP cameru z venku

« kdy: 10. 07. 2020, 09:38:51 »

Přímo to nepůjde – už dlouho je nedostatek veřejných IPv4 adres, takže se používají privátní, které nejsou v internetu unikátní, tudíž se na ně z internetu nedostanete. To je i případ vaší IPv4 adresy 192.168… Řeší to nový protokol IPv6, ale není jisté, zda ho umí vaše kamera, není jisté, zda ho podporuje váš ISP, a je jisté, že ho nepodporují čeští mobilní operátoři (zatím).

Někteří výrobci kamer poskytují cloudovou službu, do které kameru připojíte a pak se přes ni dostanete na svou kameru. To by pro vás bylo nejlepší řešení. Samozřejmě to znamená důvěřovat té cloudové službě, tedy výrobci kamery – na druhou stranu, tomu už musíte důvěřovat stejně.

Komplikovanější řešení je nechat si od vašeho ISP přidělit veřejnou IPv4 adresu (obvykle je to placená služba) a nasměrovat alespoň jeden port na tu kameru. Případně může jeden port na nějaké veřejné IPv4 adrese přesměrovat váš ISP, to by vám mohl poskytnout i zadarmo.

Každopádně počítejte s tím, že je potřeba mít v té kameře aktuální firmware a bezpečná hesla. Asi nechcete, aby se na ni díval kdokoli. Ani teď s největší pravděpodobností ta kamera nebude pro případné útočníky nedostupná, ale když ji zpřístupníte z internetu, bude ještě snazší ji najít a zkoušet na ni zaútočit.

A nebo si můžete od odpůrců IPv6 nechat vysvětlit, že přístup ke kameře z mobilu vůbec nepotřebujete. 

1777

Hardware / Re:Pidi notebook

« kdy: 10. 07. 2020, 08:27:19 »

GPD Pocket 2. Předchozí verze oficiálně podporovala Ubuntu, nevím, jak je na tom verze 2. Ta verze 1 měla klávesnici trošku nevhodnou pro češtinu (klávesy „ú“ a „ů“ jsou přilepené tam, kde zrovna bylo místo), Pocket 2 layout klávesnice změnil (ale nezkoumal jsem, jak přesně). Ale 7palcový displej je fakt malý, hodí se to na cestování, ale do postele bych asi zvolil o něco větší – přeci jen ten kompromis velikost+váha/pohodlí asi budete chtít přeci jen trochu blíž tomu pohodlí.

1778

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 09. 07. 2020, 13:04:23 »

Tak už to budete mít vyřešené i pro ODVR od CZ.NICu: Otevřený resolver od CZ.NIC vypíná ochranu proti DNS Rebinding a úpravuje DoH.

1779

Hardware / Re:Power banka s USB hubem

« kdy: 30. 06. 2020, 19:19:56 »

Napájet z toho i mobil podle mne půjde jedině v případě USB-C PD. Na klasickém USB nemůžete něco připojit k mobilu a zároveň „v protisměru“ mobil nabíjet. Řešením je podle mne (jako píše Ondra Němeček) USB hub napájený externě přes USB konektor plus powerbanka. I z toho důvodu, že v powerbance bude odcházet baterie a za pár let pořídíte powerbanku s daleko větší kapacitou, a bylo by zbytečné s tím vyhazovat i hub. Ale asi bude problém sehnat hub s externím napájením USB konektorem, většinou mívají kulatý konektor (což moc nedává smysl, ale je to tak).

1780

Odkladiště / Re:FM radiopřijímač s přímo přístupnou pamětí

« kdy: 27. 06. 2020, 10:59:59 »

Zkusil bych podle obrázků vytřídit ty, které mají číslovaná tlačítka – a pak podle návodu zkontrolovat, zda tlačítka opravdu mají požadovanou funkci. Třeba tohle to umí už podle popisu: https://www.mall.cz/radia/technisat-techniradio-rdr, tohle má tlačítka a bylo by potřeba ověřit podle návodu: https://www.mall.cz/radia/trevi-dr-730-m-cerna Klíčové slovo asi bude „přímá volba“.

1781

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 26. 06. 2020, 08:50:08 »

Takových domén asi nebude mnoho

Nejčastější negativní odpovědí bude „název neexistuje“, NXDOMAIN. Bude se vracet např. pokaždé, když někdo při psaní adresy do prohlížeče udělá překlep a adresa nebude existovat. Neříkám, že by to muselo server moc vytěžovat. Spíš jde o to, že hledáte obecné řešení vašeho konkrétního problému, ale zatím je to zobecnění docela vágní a zdá se, že ignoruje souvislosti.

Podle mne je pro vás nejjednodušší přestat používat ODVR CZ.NICu. Pokud vím, např. žádný z poskytovatelů „4x“ DNS resolverů (Cloudflare, Google, IBM) RFC1918 adresy neblokuje, takže alternativy jsou. Já ODVR CZ.NICu právě kvůli tomu blokování RFC1918 nepoužívám. Protože sice chápu, co se tím sleduje, a že starší doporučení tvrdí, že se RFC1918 nemají objevit ve veřejné DNS, ale v současné situaci, kdy veřejné IPv4 adresy nejsou, považuji privátní adresy ve veřejném DNS za nejmenší zlo – a veřejný DNS resolver by je podle mne neměl blokovat, rozhodnutí by mělo být na koncové síti.

1782

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 25. 06. 2020, 14:57:11 »

Vy máte nějaké využití pro neveřejné adresy ve veřejném DNS?

Když se neveřejné IPv4 adresy používají kvůli nedostatku veřejných IPv4 adres. Stejně chci k zařízením s takovou IPv4 adresou přistupovat přes DNS název – k serverům, routerům, webkamerám, NASům apod. Ne vše ještě podporuje IPv6. Dělat kvůli tomu split-horizon DNS je práce navíc, je pak problém, když přecházíte mezi sítěmi a někde zůstane nakešovaná negativní odpověď. Pokud někdo ten DNS název zjistí a veřejném DNS si to přeloží na privátní IPv4 adresu, ať si znalost té privátní IPv4 adresy užije, mně to nevadí, že ji zná.

1783

Sítě / Re:Jak co nejlevněji zpřístupnit stroj za NAT

« kdy: 22. 06. 2020, 19:25:58 »

Ano podobne riesenia zvazujem ale ich problem je ze funguju systemom, ze sa musim prihlasit do nejakej siete (VPN) aby som sa dostal na moj stroj, miesto toho aby som siel priamo bez nutnosti tychto tunelov.

ngrok nebo Serveo vám ten port zpřístupní na normální veřejné IPv4 adrese.

Bohuzial zmena je tiez zlozita. Este zvazujem optiku od Telecomu tam si ale nemozem byt isty ci vzdy budem mat verejnu ipv4 alebo mi ju jedneho pekneho dna zrusia. Tatiez tie krabicky ku optike nemam kde odlozit. Viac menej ani nemam velmi na vyber.

Kdyby to bylo jednoduché a zadarmo, už byste to asi měl dávno vyřešené. Holt s tím nějaké náklady budete mít – buď se změnou ISP, nebo za IPv4 adresu u daného ISP, a nebo s nějakým tunelováním.

Odpůrci IPv6 pořád tvrdí, že není potřeba, tak tady vidíte, jak je to ve skutečnosti – to, že není IPv6 dostatečně rozšířené, vás reálně stojí a bude stát peníze.

1784

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 18:47:38 »

Vznikají v tom kódu nové objekty?  - ANO, vela
autoboxing - ANO, vela
Spouštíte to v obou případech stejnou Javou? - ANO

Na ten GC jste se díval? Normálně bych se jen podíval přes jconsole na graf využití paměti. Podle toho, jak to popisujete, mne jako první věc napadá, že v jednom případě naráží GC na limit paměti a musí uvolňovat objekty, zatímco v druhém případě to dělat nemusí (nebo ne tak často).

Případně bych zvážil vyzkoušet jiný GC, možná budete schopen aplikaci urychlit i proti tomu rychlému běhu.

1785

Vývoj / Re:Spring framework - spomalení kódu

« kdy: 22. 06. 2020, 17:09:41 »

kod je uplne primitivna matekatika (+,-,*,/), ale pouzita X tisic/milion-krat spolu s  java kolekciami (mozno problem niekde okolo hashcode/equals), ziadne spominane "pokrocile technologie".

Vznikají v tom kódu nové objekty? Třeba i jen kvůli autoboxingu? Podíval bych se na GC, zda nenaráží na limit paměti. Spouštíte to v obou případech stejnou Javou? Nemáte tam při tom spuštění z Eclipse zapnutou nějakou instrumentaci?

Snažil bych se dřív vyloučit jiné vlivy – profilování není nic jednoduchého, a zejména pokud to někde běží rychle a jinde pomalu, je dost možné, že to spuštění pod profilerem ovlivní natolik, že stejně nic nezjistíte.