Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - M_D

Stran: 1 2 [3] 4 5 ... 12
31
Sítě / Re:T-Mobile - slovenská GeoIP
« kdy: 22. 03. 2021, 12:57:51 »
Řekl bych to tak, že operátoři se obvykle nějak snaží, aby ty data v těch GeoIP databázích tak nějak seděla. Aspoň u těch nejprofláklejších, ale nemají šanci to vše obstát a někteří provozovatelé těch DB jsou dost natvrdlí ohledně změn. Ale není to žádná povinnost, jen dobrá vůle. A koncový zákazník má minimální šanci něco u GeoIP DB  změnit (pokud není na něj blok IP veden někde u RIPE a spol, tak se s ním nikdo nebude bavit), takže správně má prskat primárně u provozovatele služby, co ho blokuje (protože jen ten nějak ví, dle čeho ho vlastně blokuje).
Když vezmu, že změnit data u maxmind.com, protože člověk chtěl mít správně údaje na výpisech u speedtest.net (který používá GeoIP od maxmind), tak to bylo na hodně dlouho. Vysvětlit jim, že když jsou data dle RIPE v státu X, tak dané bloky mohou být použity i v místě Y, když tam daný ISP také půdobí...
A nejdebilnější je to u státní správy, když blokuje dle GeoIP. :-(

32
Server / Re:Viac ako jeden web server za verejnou IP
« kdy: 16. 03. 2021, 11:38:49 »
Pro trvalé řešení ta zmíněná reverzní proxy (jde použít cokoliv - haproxy, nginx, ... i v tom apache to jde udělat). Pokud je to jen na hraní a pokus a v roli toho NATu mám Mikrotika, tak pro HTTP umí dělat reverzní proxinu (ale nehodí se to pro nasazení do ostra) a pro HTTPS umí směrovat na základě požadavku TLS host (SNI).

33
Server / Re:Databáze - 300 GB tabulka
« kdy: 15. 03. 2021, 22:07:29 »
Také mám 300GB+ tabulky v PostgreSQL a jde to. Pokud chápu tazatele, tak má data, co musí naimportovat hromadně 300GB, zpracovat, zahodit a za čas znovu.
Pak bych se zamysle nad tím Postgresem, možná včetně nadstavby TimescaleDB, mohlo by to být rozumně použitelné. Zazněl InfluxDB, tak mám zkušenost, že dávkový import velkého množství dat není žádný rychlík a co jsem se díval, tak podobě to vycházelo u dávkového masivního importu pro Cassandru. U Influxu také dotazy přes větší sady dat dost drhnou (jak to začne de/kompresovat) u toho TimescaleDB by to mohlo být průchodnější při potlačení komprese. Nebo použít navrhované partišny po nějakém časovém bloku, pokud nechci do toho PgSQL tahat TimescaleDB.
Určitě to dost ovlivní indexy, nevhodně složitý trvá pak jeho sestavneí a žere dost místa. U takovéto jendorázové operace by se mohl hodit hash index, sestavoval se rychleji a zabíral méně místa, než klasické btree (a zlomek třeba proti gist), ale nevím jak poslední verze PgSQL, dříve (do PgSQL10) nebyl spolehlivý z pohledu nutnosti reindexace po restartu DB, ale pokud celé zpracování proběhne během jednoho běhu DB a nepotřebuji vlastnosti, co hash index nemá (nepodporuju unique, vícesloupcový index, sorted index a možná ještě něco), tak by mohl pomoci s urychlením.
A pokud jde o časové řady a imporutji data, co jsou už relativně utříděné (což je urychlení vždy), tak i brin indexy pomohly.

34
Studium a uplatnění / Re:Kam jako programátor po 50 letech?
« kdy: 10. 03. 2021, 21:52:15 »
Jste mě vyděsili, pade za chvíli na krku a pokud člověka nezabije corona, co pak...
U nás se říkalo, že kdo to umí,t en to dělá, kdo to neumí, ten to učí a kdo to neumí učit, ten to řídí. :-)

Bude asi problém, pokud člověk jen lepil něco v mainstreamu, styl PHP+jquery, že tam konkurence bude velká u mladého houfu. Pokud umí něco exotičtěji specifického, tak bude mít asi šanci stále.
Pak jsou obory, kde je nevybouřené mládí spíše nevýhoda a má šanci starší, pokud něco umí. Třeba i v ČR se vyvíjí SW s přímým vlivem na jadernou bezpečnost (A+  - chyba v SW vyvolá jadernou havárii - dobře, dle PR přesněji vyvolá nestandardní událost v oblasti radiační bezpečnosti :-) ). Tam je vzhledem k přístupu a postupům šance a normou i máte nalinkováno, co a jak přesně máte psát (goto nám zakazují :-( ) a odpadají nadržená štěnata, co se nechtějí zabývat několik let prvně myšlenkou, zda zadání neodporuje žádným známým fyzikálním, chemickým, matematickým... zákonům, je úplně jednoznačné atd, než napíšu první řádek. :-) OK, těch firem je asi tak 3 ks. :-(

Add odejít z oboru jinam, po letech se vrátit. Asi se to úplně nevylučuje. Exšéf si udělal 15 let pauzu - pasení ovcí na horách. A pak šel do firmy, kde nyní vyvíjí SW pro autopila do vrtulníku. Nastupní věk 55+. Před 35-ti lety psal SW na počítání projíždějících vagónů v Module2 pro ADT4500, pak nějaké zpracování technologických dat pod MSDOS na PC a končil jako vývojář na TurboPascal/Delphi1.0 pod Windows3.11.

Takže najít se dá, druhů věc je, jak to člověk ještě dá... V řadě případů je to o tom, že je i jiné vzdělání/znalosti, než jen IT.

35
Sítě / Re:Vybudování vlastní optické přípojky
« kdy: 05. 02. 2021, 16:40:10 »
Zákoš má stejně ve většině případů doma i router, ten se sere úplně stejně jako ten GPON ONU. U většiny lidí je router stejně dodaný od ISPíka a pokud se posere, tak to řeší ISPík a nakluše jeho technik stejně u ODU i Ethernet routeru (pokud se bavíme o alternativcích a ne velké trojce). Pokud se posere ta centrální krabička, nejede celý barák, pokud se podělá jednomu koncákovi, tak prudí jen ten jeden. Jistě, jsou i ISPíci, co simulují zákošův router na tom svém centrálním routeru v baráku a zákoš tak router nepotřebuje, strčí si tam jen switch nebo APčko a jede, ale to je celkem minorita.
Důvod rozvodů FTTB u rezidentů je hlavně historický, GPON byl neuplatitelný pro menší ISPíky, tak jedou PtP optiku na barák a tam ten switch. A pak samozřejmě konverze, kde původně bylo rádio na střeše, tak je někde switch a při dotažení optiky se jen vymění uplink rádio za fiber a barák se nepředělává, tam asi není o čem diskutovat.
Dneska se dá GPON koupit už za rozumnou cenu, takže je možnost optika až k tomu koncákovi a míc pokoj u novo instalací, pokud už tu optiku k baráku dokopu.

36
Sítě / Re:Vybudování vlastní optické přípojky
« kdy: 03. 02. 2021, 22:40:53 »
Ať mu doma skončím optikou nebo metalikou, stejně tam má obvykle něco jako router/switch/AP, který potřebuje elektriku, takže když má doma GPON ONU bránu, tak v tom rozdíl už není. Jistě, záleží co ISPík nabízí, zda jen ONU bránu s routerem v jednom nebo i ONU bridge za který si zákoš dá svůj router (v tom případě je to o krabičku/zásuvku víc). Stěhuje se kolikrát lépe ta optika, protože se optický patchcord dá schovat lépe, než UTP kabel (třeba jsem ho zamačkával do spáry mezi parketama, aby nebyl vidět napříč bytem).
Zatím se lépe vždy tahala optika. Zkrátka ve stoupačce pro 12-ti patrovej barák s třema byty na patře je to jeden kabel z kterého se vypichují 3 vlákna na patře než bago třiceti UTPéček. Samozřejmě to chce zásuvku ukončit hned po průchodu zdí, aby rozvod byl před uživatelem schován. Dál pak pathcord potřebné délky, když si ho štípne položením skříně, tak se vymění kus za kus.
S tím switchem zkrátka je dneska už víc sraní technicky i legislativně (vlastní odběrný bod, pokud je to děláno během výstavby ového domu, tak to má bát odolné zaplavení vodou a další blbosti).
Ale zprznit jde cokoliv. Blbec přo stěhování ti klidně Ethernet WAN port nacpe do LAN strany a diví se pak, že to nejede. :-)

37
Sítě / Re:Vybudování vlastní optické přípojky
« kdy: 03. 02. 2021, 20:56:08 »
*dneska* vubec nedava smysl nejaky switch v suterenu a tahani metaliky po dome
Tohle by mě celkem zajímalo, můžete to rozvést?
U GPONu mám v baráku jen pasivní optickou část, nic napájeného (což může být dost problém), co musím odněkud řešit a co se může také někdy podělat. Zkrátka přijdu do baráku jedním kabelem, na něj se hodí optikcý pasivní splitter a rozáhne po baráku optikou, vlákno na byt a je to i mnohem méně náročné na prostor, než tahat bago UTP kabelů stoupačkama.

38
Software / Re:Bezpečné používání mqtt a redis v internetu
« kdy: 01. 02. 2021, 18:56:17 »
U MQTT asi půjde o to, jaký server je nasazen. Ale i ten základ v podobě mosquitto, tak už umí nativně TLS i s ověřováním klienta na základě předloženého certifikátu. To stejné Redis, od řady 6 je nativně podporán TLS, včetně ověřování klienta certifikátem.
Jiná věc je pak ta klientská strana, aby to uměla použít. Oboje také podporuje ověřování username+password (u Redisu <6.0 je teda jen jedno sdílené password).
Pokud jsou myšleny systémové logy typu syslog, tak je otázka, proč neopužít třeba syslog-ng, který umí nativně také odesílat logy přes TLS spojení, včetně bafrování na straně klienta při přerušení spojení a na straně serveru ověřit klienta dle certifikátu.

39
K těm atramentovkám. Asi bude záležet na typu. Jak tu chválil kolega incorporated Brothera - já mám 10 let starého A3 tisk/scan/duplex MFC-J6910DW, počítadlo hlásí aktuálně 5.093 stran (a teprve poslední rok to poskočilo, jak ji smradi trápí na distanční výuce stylem tisk-vyplnit-naskenovat). V A3 barevný laser na doma nezaplatitelný, v bublině stál tenkrát něco přes 10 kKč s 3 roky doma servisem. S originál náplněmi nezasychá (používám větší sady LC-1280), černou teď dojíždím třetí náplň za těch 10 let (uvádí výdrž 2.400 stran), barevné mám pátou sadu (mají mít 1.200 stran). Plus tím prošla startovací dodaná sada (600 stran černé i barevné). Některé náplně jsem měl doma přes 5 let (ty aktuálně použivané mají psanou použitelnost do 2015.02), než jsem je vybalil a přišly na řadu.
A jak píše kolega Ryšánek výše k těm neoriginálním náplním - vloni v dubnu jsem koupil poprvé na zkoušku i barevné neoriginál za třetinovou cenu. Na podzim nasadil žlutou, tiskárna hlásí z půlky prázdnou a je zaschlá.

40
I místní prodejci Supermicra pro něj nabízí onsite NBD na 3 nebo 5 let. Pravda, něco to stojí (třeba cca 40 kKč pro šasi s osmisystémem SYS-5039MC-H8TRF za 520 kKč).

Je otázka, zda by za těch 100 kKč dokázal koupit 2 šasi od QNAPu nebo Synology s podporou pro live replikaci iSCSI svazků. Myslím, že s trochu štěstí ano  a pár let to vydrží, než chcípne ten vlastní HW serverů. U Synology jenom pozor, že je tam požadavek na odezvu mezi šasi do 1 ms, takže nejde tak třeba replikovat 2 šasi Brno-České Budějovice, Albert nám dal rychlost světla příliš nízko. :-)

By mě zajímalo porovnání třeba CEPH kontra GlusterFS. GlusterFS používáme 2 servery, někde 3 servery, co se vzájemně synchronizují lokální SSDéčka přes vyhrazené 10 Gbps propoje a nad tím virtuály. Jako podklad CentOS7 s cluster suitem, nad tím KVM a hromada virtuálů, kupodivu celkem OK pro pár desítek virtuálů, kde jsou i celkem velké PostgreSQL InfluxDB a Oracle databáze s pár seg giga až tera daty.
Pokud se nám na tom v posledních letech někdy něco podělalo, tak to byly servery se sdíleným externím SAS polem (GFS2 filesystém), když nějak blbě lehnul některý z řadičů v řádu měsíc-dva po skončemí záruky na HW. :-)

41
Vývoj / Re:Jak posunout vývojáře k CI/CD
« kdy: 30. 01. 2021, 12:48:52 »
Longin: V postupech pro používání open source knihoven je, že chyby se reportují/opravují/commitují zpět autorům/testují v rámci vývoje v normální pracovní době. Je i stanoveno, že pokud potřebujeme něco do knihovny přidat, tak se to udělá a postne do původního projektu (už jen proto, že táhnou sebou vlastní úpravy a nasazovat to do každé nové verze je po čase peklo, tak je lepší to dostat do původního projektu). Nebo i pokud potřebuji dostat něco nového do open source věci, tak si na to někoho najmu jako jendorázovku se zadáním doplň do X funkcionalitu Y, za to je P1 odměna, pokud dojde k úspěšnému včlenění do stromu dané knihovny, je k tomu P2 bonus.
Jistě, je komplikace, kdy jsem i autor/spoluautor té open knihovny a zároveň ji používám v rámci zaměstaneckého projektu. Tam musíš mít tu domluvu jasněji s firmou dánu. Ale obecně z mého pohledu, pokud si vyvíjím něco na sebe a pro sebe primárně, tak to mám zveřejněno pod svým soukromým jménem/mailem (protože firemní pravidla zakazují třeba používat v soukromých záležitostech vazbu na firmu-firemní email). Pokud to používán i v pracovní náplni, tak pokud mám dohodu, že to opravuji/vylepšuji jako součást práce, tak toto commituji pod firemním ID. Pokud to opravuji ve svém volném čase, tak pod firemním dám jen ticket a pracovně čekám, až se k tomu ve volném čase dostanu a opravím. :-)

K tomu technologovi - Že si technolog udělal pomůcku pro sebe, postup je dám v těch knihách, co měla firma, logaritmické pravítko jim neukradl. Mohl si klidně napsat v pár bodech poznámku do mobilu, jak to linku najet a pokud to najíždí X let sám, nikdy další mu do toho nekacal, tak nikomu nemusí dojít, že je to tak je.
Tohle uteče občas i ve firmě, kde máš přímo proces a desítky lidí na to předávání zkušeností další generaci, na vše postupy, testování na simulátorech, navíc obsluha striktně má postupovat podle stanovených postupových knih (nejste tu od toho, abyste mysleli, ale šli podle postupu) a stejně se občas stane, že se pak zjistí, že se něco nepředalo pro další.
Známého takhle vytáhli z důchodu zpět do práce, přesně z tohoto důvodu, přestože cca 2 roky před odchodem v podstatě byl už jen "vytěžován" z jeho znalostí a rozhodně nebylo nic ve snaze zatajit (protože ta rozlučková důchodová prémie je taková, že asi každý si rád jde do důchodu s jednorázovým bonusem u některých v řádu MKč).
I my tento týden jsme opatrně zjišťovali, zda exkolega, co šel do důchodu cca 10 let zpět ještě žije, zda by se nám na něco nepodíval, sice k tomu vše máme, umíme to, ale mladoši to v podstatě nikdy nědělali, tak zda by na ně za nějaký bonus nemrkl na to vyhodnocení dat a neřekl jim k tomu své.

42
Vývoj / Re:Jak posunout vývojáře k CI/CD
« kdy: 30. 01. 2021, 10:42:47 »
Longin: Nu, měl bys mít v dokumentaci podchyceno co ten projekt potřebuje za externí knihovny, jejich seznam, licence, odkazy na autorství a nějaký vedoucí projektu by to měl schválit. U většího ti do toho bude rejpat tým právníků a případně i oddělení kybernetické bezpečnosti. Pokud jsi sám jediný na to celé, tak je to ošemetnější, ale ten seznam a odkýváno od šéfstva by byl žádoucí s upozorněnímna konfliktní stav. U toho by ti mohlo i vyplynout dohoda o tom, jak s těma knihovnama dále bude nakládáno, řešeny chyby, doplňování funkcionality v nich (u komerčních postup reportace autorům/ověření po nápravě, u volných třeba i to, že v rámci práce chyby opravíme a pusnem zpět ke sloučení, pokud autor sám nezareaguje).

43
Vývoj / Re:Jak posunout vývojáře k CI/CD
« kdy: 30. 01. 2021, 10:34:40 »
Ink: Napsal jsi pěkně, jak by to mělo být. Ale ono to tak většinou není, hlavně bod 4. :-)
I dotaz tazatelel ukazuje, že to tak u něj není. A můžu tě ujistit, že je to tak u spousty firem. Lepší to bude v IT firmách, kde vývoj je jejich core.
A ano, je to hlavně o lidech a i o tom středním managementu, jak se v oblasti orientuje.

Když se bavíme o jiných oborech, kde si vedou vývoj jen jako součást, tak se k tomu stavu blíží jen ve velice specifických oborech (pokud je k tomu tlačí něco navíc - dozorově, legislativně, ...). Ono třeba verzovat binárná bordel z vývojového nástroje k automatu je peklo. Že by to umělo samo to klikátko, to je pěkné iluze. Tam je už zlaté SVN proti GITu, pokud budu muset začít do toho strkat velké objekty a hlavně bináry. A pokud pokrokově zapnu ukládání do XML místo bináru, tak projekt místo 17 MB má 2,3 GB, na to, že to má jen umět odpojit rozvodnu při zkratu. A pak zjistíš, že ten XML umí načíst zpět jen ten stejný nástroj ve stejné verzi a ještě v tom XML není úplně vše, co v bináru. Po aktualizaci na novější nenačte, umí načíst ze starší verze jen ten binár (co bych ctěl, když jedna vývojové offline licence stojí jen 15 MKč). :-) :-)

44
Sítě / Re:Přístup zvenku na IPv6 u O2
« kdy: 29. 01. 2021, 17:04:46 »
O2 dává v tákladu přes DHCPv6-PD jeden /64 blok pro vnitřek sítě, takže žádná sláva. :-)

45
Sítě / Re:Přístup zvenku na IPv6 u O2
« kdy: 26. 01. 2021, 19:32:16 »
Příchozí IPv6 u DSL i GPON sítě O2 funguje, snad blokují jen příchozí UDP/53.
Jen upozorňuji, že některé hodně historické Comtredy měly "vlastnost", že neuměly propustit korektně IPv6 ani v bridge režimu, zkrátka IPv6 natvrdo dropovaly, ale typ si už nepamatuji, to byly počátky IPv6 u O2 (a všude to spolehlivě řešila náhrada v podobně jednoportových Zyxell). :-)
FR: Mikrotik něco jako tcpdump umí (pokud nestačí Netwatch na L3) - Tools / Packet Sniffer.

Stran: 1 2 [3] 4 5 ... 12