Příspěvky

916

Sítě / Re:Síť po dvou drátech

« kdy: 18. 04. 2019, 15:42:46 »

For the record, žůžové průmyslové SHDSL modemy (Ethernet extendery) dělá Westermo, ale za tu cenu to nechcete "na takové to domácí žvýkání".

A leased-line async modemy jsou samozřejmě taky možné, ale rychlost stojí za prd a navíc byste museli routovat skrz PPP = na každém konci navrch odhadem Malina nebo Mikrotik. A cena nových průmyslových modemů opět není zrovna žůžo.

SHDSL je symetrické = shodná rychlost oběma směry, možná i dvě shodné krabičky proti sobě. Přesto i tady se obvykle konfiguračně volí strana "ústředny" a "koncového zákazníka" (CO/CPE). SHDSL jsem viděl chodit do 15 Mbps po jednom páru. Samozřejmě záleží na vzdálenosti. Na těch 300 m SYKFY byste měl dosáhnout třeba 5 Mbps, pokud tam nebudou přeslechy nějakého jiného provozu nebo rušení ze sousedních párů (třeba VDSL2 DSLAM obsluhující snop dalších zákazníků).

RS485 na první pohled není úplně hloupý nápad, jede to po diferenciálním páru a dá se konfigurovat baud rate. Vidělo by se, kolik proleze - ale asi moc ne, ten obdélník v základním pásmu není spektrálně moc efektivní. Na druhý pohled se na dvoudrátu jedná o half-duplexní technologii, takže PPP by po tom neběhalo, a nevím o žádné half-duplexní enkapsulaci IP over RS485. Po dvou párech by to byla jiná: full duplex RS422 a nad tím PPP. Dají se pořídit i full-duplexní izolované převodníky na RS232, nebo USB/422 dongly (jeden krásný kousek na bázi FTDI má Papouch).

917

Software / Re:UDP paket server

« kdy: 18. 04. 2019, 15:23:48 »

Jestli je možnost mít prostředníka, pak bych udělal VPNky. Latence minimální, bude to bezpečné, není potřeba měnit stávající způsob distribuce a navíc bude přístup třeba i ke správě těch vzdálených lokalit

A pokud se jedná o streaming, tak na rozdíl od holého UDP, kde opačným směrem nemusí téct *nic*, pokud bude použita VPN jako mezivrstva, tak ta mezivrstva si občas pošle opačným směrem aspoň nějaký keepalive, pokud ne rovnou TCP ACK = udrží v NATu otevřenou stateful session. Možná byste skrz tu VPN protlačil i multicast. Pokud by to utáhla OpenVPN, tak stojí za zvážení/otestování udělat tu hvězdu s enkapsulací "TAP" = celé eth. rámce a multi-exit síť (na satelitních lokalitách mezi LAN a VPN raději routovat). Otázka je, jak to celé bude reagovat na výpadky paketů = nakolik je výpadek paketu problém a statisticky jak často k němu na použitých trasách dochází...

918

Desktop / Re:Dotyková obrazovka má invertovaný dotek

« kdy: 18. 04. 2019, 12:29:29 »

Ohledně chování dotyku jsem našel jedno debatní vlákno a v něm úplně na konci asi jedinou praktickou radu:

usbhid.mousepoll=0

Což ovšem může mít vliv pouze v případě, že je dotykový řadič vidět uvnitř systému jako zařízení třídy USB HID.

Dotaz do googlu vrátil nějaké další výsledky...

919

Desktop / Re:Dotyková obrazovka má invertovaný dotek

« kdy: 18. 04. 2019, 12:21:01 »

Ohavná self-promotion. Popravdě tomu dal korunu kolemjdoucí Petr Mikše (na odkazované stránce je zmíněn).

Toto zkalibruje souřadnice. Ohledně logiky dotyku (posouvat vs. drag and drop) z hlavy neposloužím. Mohl by na to mít fidlátka buď xinput nebo HW-specifický ovladač. Debilní logiku dotyku jsem řešil spíš u nativní podpory pod Windows, v Linuxu se mi to zatím vždycky chovalo použitelně... Nebyl by případně nějaký popis, co je zač ten dotykový kontrolér? Visí to na USB, 232, I2C ? Nebyl by útržek logu, kde ho kernel nebo xwindows nadetekovaly ?

920

Hardware / Re:Doporučte DVB-T2 USB tuner s podporou Linuxu (Debian)

« kdy: 12. 04. 2019, 15:12:56 »

Ten klon Astromety, jak ty rikas "smejd", je totiz aspon provereny. Kdyz pujdes po tyhle verzi:

tak jdes prakticky na jistotu. Coz se o Averu nikdy rict nedalo.

Ono to vypadá, že ten klon, co má kabátku natištěno SDR, už není dostupný.
Přikládám obrázek čehosi velice podobného, akorát ten potisk na kabátku už je jiný -> odhadem už tam nemusí být RTL2832P jako hlavní čip s USB rozhraním... Pokud jste to někdo potěžkal v ruce tak poreferujte USB IDčka a čipset. Každopádně já zatím nevyhazuju svůj starší dongle s RTL2832U.

921

Server / Re:Gmail přijímá moje zprávy do spamu

« kdy: 15. 03. 2019, 08:10:08 »

Přikláním se k názoru, že Google nasadil na filtrování SPAMu AI, která hodně přihlíží k "reputaci", kterou si sama nasbírá. AI šetří lidskou pracovní sílu (obsluhu antispamu). Osobní zkušenost: o štědrém dnu někdo uhodl uživateli heslo na SMTP a pak botnet přes vánoční svátky skrz náš mailserver vesele valil SPAM, než si toho 27.12. někdo všiml. Nasbírali jsme tolik černých puntíků, že trvalo další asi dva-tři týdny, než nás G-Mail přestal šmahem kostit už při EHLO. Ty 2-3 týdny jsme byli samozřejmě už "čistí", díra zavřená, vyháknutí z těch asi 4 blacklistů co si nás všimly (třeba SPAMcop si nevšiml). Na ruční zásah obsluhy G-Mailu jsme zjevně příliš malí. Google je velký a Google to má správně, AI je moudrá. Ke zvrácení reputace je zřejmě potřeba, aby po nějakou dobu počet "neškodných" mailů převážil počet SPAMů. Resp. než nahromaděná statistika (četnost) SPAMů zastará / uplyne časové okno apod. Statistika se těžko nějak rychle zlepší v situaci, kdy jsou příchozí maily odmítány už při EHLO, bez ohledu na obsah. Pravda je, že i v době, kdy jsme byli v nemilosti, tu a tam nějaký e-mail prolezl, bez zjevného důvodu. To se pak člověk nediví populárnímu nesmyslu, že u neuronové sítě její stvořitel netuší, proč se rozhodla tak jak se rozhodla, nejsou nástroje jak "vizualizovat naučená pravidla" apod.

922

Vývoj / Re:Viděli už jste někde distribuované transakce?

« kdy: 21. 02. 2019, 08:21:52 »

Zkusil jsem zagooglit Distributed Transaction Manager. Protože to možná kdysi bejvalo k dispozici i jako "nezávislá služba".

Jedno zajímavé video z novější doby - neméně zajímavé jsou komentáře pod videem :-)

923

Vývoj / Re:Viděli už jste někde distribuované transakce?

« kdy: 20. 02. 2019, 06:37:20 »

Dělám do včel. Živě si pamatuju se školy na konci 90.let tehdy módní téma distribuované databáze, a vrcholným číslem měl být právě 2-phase commit (2PC). Pokud si pamatuju, přednášeli nám o něm v obecné rovině, ne že by nám ho někdo předvedl (jak se to konfiguruje na nějakém reálném RDBMS). Ano určitě to zdržují latence. Tzn. hodí se to podle mého ve scénářích, které jsou "read mostly" = ta trocha zdržení při zápisu aplikaci nezabije a čtení rozložené mezi N uzlů výrazně zvedne průchodnost (a bude to mít také dobrou spolehlivost, pokud zároveň funguje nějaký failover v clusteru).

924

/dev/null / Ověřování vlastnictví domény TXT záznamem - divná móda...

« kdy: 19. 02. 2019, 11:27:28 »

Já jsem asi vážně mimo a asi už i dost dlouho. Přišel kolega "hele potřebuju TXT záznam v DNS, kvůli jednomu kancelářskému SW balíku. Prej abych dodavateli ověřil, že legitimně užíváme doménu, na kterou je u nich v cloudu napojené naše předplatné, které mám správcovat." Zdvihl jsem obočí, na ověření identity u projevu vůle mezi firmami jsou přece dávno zavedené jiné postupy a inštrumenty, ale říkám "jasně, vím co je TXT záznam, tak mi dodej jak se má jmenovat a co má obsahovat". No a trochu mě nadzdvihlo, když mi přišlo "jméno: @"  . To si jako třetí strana dupne, že chce svůj TXT záznam přímo na 2nd-level jméno naší DNS domény?

No evidentně ano. Pokud se týče mého duševního rozpoložení, trochu mě uklidnilo, že ten TXT záznam na 2.úrovni není exkluzivní. A nakonec jsem zjistil, že zmíněný konkrétní provozovatel cloudové aplikace tuhle fintu zřejmě sám nevymyslel.

Není potřeba ani složitě googlit, kdo všechno tohle svým klientům dělá. Zkuste si vypsat "host -t txt $domena" kde za $domena dosaďte 2nd-level doménu libovolné veliké firmy nebo třeba úřadu na celostátní úrovni (mluvím o firmách v roli dotčeného uživatele).

Kde je nějaká ohleduplnost / pořádek? Přístup "řádného hospodáře" ve správě DNS? Vždyť i DKIM si skromně vystačí se jmény čtvrté úrovně (jsou navěšena na jediném jméně 3.úrovně _domainkey). Kdyby se tahle móda (každý svůj TXT záznam na 2nd-level doméně) rozmohla i v druhé a třetí lize SAAS poskytovatelů, tak se nám to DNS pěkně zaplevelí. Celé to vypadá jako přetlačovací hra. Kdo posprejuje víc nároží svojí muří nohou. Kdyby se tohle standardizovalo = vyrobit na to well-known subdoménu třetí úrovně např. _owner_validation (helemese podtržítko), byla by to pro rozpustilé megakorporace jistě mnohem menší sranda. Hehe oni to po sobě chtějí nejspíš i *navzájem* ;-)

925

Sítě / Re:Propojení dvou bodů (AP+klient)

« kdy: 14. 02. 2019, 13:18:02 »

Pokud Mikrotik tak na AP je pro multipoint potřeba minimálně licence L4, na klienta a tuším i na point-to-point AP stačí L3.

Řekněme, že tu wifi "páteř" pojedete ve 4-adresním režimu (tzn. konzumní klienti typu Windows/Masox/patlafony se nebudou moci připojit). 4-adresní režim má výhodu, že neschovává=nepřekládá MAC adresy sítě za wifi klientským boxíkem. Ve 4-adresním režimu se pojítko chová jako standardní bridge a nemáte problém navazovat relace směrem od APčka do sítě schované za bridgujícím wifi klientem. (Ve standardním 3-adresním režimu je to problém.)

Pro 4-adresní režim jsou u Mikrotiku dvě proprietární varianty konfigurace:

A) point-to-point. V tom případě je AP v režimu "bridge" a klient v režimu "station-bridge".
    Na tohle tuším stačí licence L3 na obou koncích.

B) point-to-multipoint. V tom případě je AP v režimu "AP-bridge" a klient opět "station-bridge".
    Režim AP-bridge vyžaduje licenci minimálně L4.
    Pokud správně rozumím, AP softwarově bridguje provoz mezi klienty navzájem,
    z rádia na rádio (pokud se nějaký takový provoz vyskytne) a taky si musí vést
    forwardovací tabulku (mapu) koncových MAC adres na MAC adresu next-hop rádia.

V obou těchto proprietárních variantách se každopádně rozlišuje AP vs. klient.
V tomto se proprietární 4-adresní režim Mikrotiku odlišuje od "standardního" WDS, kde jsou si všechna rádia rovna (a má takisto svoje ďalšie špecifiká).

A nebo jděte do Ubiquiti - je to hodně "jablečné" a "just works". Ačkoli ohledně 4-adresního režimu nevím, to jsem na Ubnt nikdy nezkoušel.

926

Sítě / Re:Mikrotik - přes WIFI značně rychlejší upload než download

« kdy: 13. 02. 2019, 22:50:57 »

Ale já musím souhlasit, že tam je rozdíl v modulačních rychlostech, a že prostě ve směru "upload" se modulační bitrate naváže rychlejší :-) Je mi záhadou "proč", ale je to prostě tak.

927

Sítě / Re:Mikrotik - přes WIFI značně rychlejší upload než download

« kdy: 13. 02. 2019, 07:10:14 »

Tzn. ty dvě rádia (mikrotik proti klientovi) jsou de facto "peer to peer". Nejsou tam další klienti, kteří taky sosají z toho samého AP.

Řekněme, že za to skutečně můžou navázané modulační rychlosti (bitrates), a nikoli třeba download Windows Update probíhající paralelně s měřením ;-)

V tom případě je otázka, proč se rádia v upload směru (TP-link -> Mikrotik) dohodnou na větší modulační hloubce (bitů na symbol) než ve směru  download (Mikrotik -> TP-link). Jedná se o wifi, takže šířka rádiového kanálu v MHz bude oběma směry shodná. Pokud v tom nebudu hledat jiné záludnosti a implementační rozdíly / bugy, tak bych řekl, že rádio od TP-Linku vnímá na příjmu horší odstup signál/(šum+rušení) než rádio od Mikrotiku - proto si TP-Link řekne o nižší přenosovou rychlost. Chtělo by se říci, že má TP-link prostě horší anténu, ale to není nutně příčinou, protože pasivní rádiová cesta mezi oběma rádii má oběma směry shodný útlum (shodné antény, shodný frekvenční kanál). Žeby TP-link měl na příjmu vyšší úroveň rušení? Protože širší vyzařovací diagram? Nebo má jeho RX horší vrozené šumové číslo (vlastnost "křemíku")? Nebo do něj ruší zblízka hostitelský počítač?

Co se stane, pokud TP-link dongle vzdálíte od počítače pomocí USB prodlužováku?

Ještě bych si troufl od oka navrhnout experiment, "vykašlat se na MIMO a použít jediný chain na každém konci", což by možná zlepšilo stabilitu spoje, ale zřejmě omezilo přenosovou rychlost. Kromě toho že na tom TP-link donglu to zřejmě ani nepůjde konfigurovat.

928

Server / Re:Kolik stojí 1PB úložiště?

« kdy: 29. 01. 2019, 21:01:57 »

...nebo bych zmínil německý Stordis...

Uff... s/Stordis/Starline/g . Starline dělá RAIDy. Stordis dělá HPC věci a míval tuším i nějaké storage boxy, ale dneska už zřejmě jenom switche na Ethernet/SAS/FC a optickou bižuterii. Kupodivu tam nevidím ani Infiniband... Mívali značkové SFP transceivery. Asi taky nemají na webu všechno, co jsou schopni obstarat.

Je to asi deset let, co jsem si hrál s iSCSI v rámci SCST nad Myricom 10Gb Eth a koukám, že i SCST jde dál, má drivery pro dost moderní čipy Qlogic, ale bohužel je dodnes "out of tree", na rozdíl od LIO které se dostalo do kernelu... a jako RCS používá SCST dodnes Subversion.

929

Server / Re:Kolik stojí 1PB úložiště?

« kdy: 29. 01. 2019, 09:10:07 »

Top-loading za relativně málo peněz by se asi ještě dal, ale ten fibrechannel je zřejmě fakt docela stopka :-)

Jsou trapný v tom Supermicru, že to mají všecko jako NAS (aneb "udělejte si sami iSCSI")
https://www.supermicro.com/products/nfo/storage.cfm

Jinak klasické kastle se šuplíkama zepředu si začala sama prodávat taky Areca, nebo bych zmínil německý Stordis - mají nějaká svoje noname šasi (kromě toho že zastupují Infortrend)

930

Distribuce / Re:Skvělý Linux na míru

« kdy: 21. 01. 2019, 10:45:22 »

-nektere programy stare, nektere programy nove

-pripadne mit vedle sebe nekolik ruznych verzi toho sameho programu (s tim, ze pokud by kazda verze vyzadovala jine knihovny a balicky, tak mit i ruzne verze knihoven s tim, ze kazda verze programu by odkazovala na ty spravne knihovny a balicky ktere potrebuje)?

Dependency hell. Pokud chcete radikálně starší / novější verze programů, tak nejlíp asi běžet si starší verze distra ve virtuálkách. Pokud jde o to, že máte v Debianu od přírody nějakou dost uleželou verzi, a chtěl byste novější, tak si novější verze kompilujte každou zvlášť ve zdrojákovém adresáři, a spouštějte přímo z individuálního "build" adresáře = bez instalace, pokud to lze (i tak bude legrace řešit verze knihoven, pokud nevyhovuje standardní varianta, že je v systému více číslovaných verzí téže knihovny, modulo garance zpětné kompatibility mezi minor verzemi). Na posledním "Debianu stable" obvykle zkompilujete nejnovější vývojové verze všeho možného. Hmm přemejšlím jestli lze snadno spouštět grafické aplikace (pod X) chrootnuté v nějakém sandboxu. Jasně flatpak.