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 - Filip Jirsák

Stran: 1 ... 126 127 [128] 129 130 ... 375
1906
Distribuce / Re:Xubuntu 19.10 a 20.04LTS nefunguje sudo
« kdy: 09. 05. 2020, 20:07:17 »
Spouštět grafické programy pod rootem vážně není dobrý nápad, navíc takhle divně přes sudo z příkazového řádku. Je možné, že vám nikdo neporadí, protože to tak nedělá. Nějaké info najdete třeba zde: https://wiki.archlinux.org/index.php/Running_GUI_applications_as_root

1907
Distribuce / Re:Xubuntu 19.10 a 20.04LTS nefunguje sudo
« kdy: 09. 05. 2020, 10:53:49 »
To není problém se sudo, ale se spouštěním grafického programu – chybí mu display manager, přes který by se mohl vykreslovat. Ten je určený v proměnné prostředí DISPLAY. Resp. ve vašem případě je DISPLAY nastaveno na :10.0, ale příslušný uživatel nemá oprávnění se k tomuto display manageru připojit.

1908
Sítě / Re:Ethernet kabel do země
« kdy: 08. 05. 2020, 19:29:04 »
Není lepší tam natáhnout optický kabel? I kvůli galvanickému oddělení.

1909
/dev/null / Re:Blockchain - kde je?
« kdy: 07. 05. 2020, 20:48:16 »
Blockchain není nic světoborného. Ten princip se používá v různých aplikacích – třeba Certificate Transparency log nebo git.

1910
Vývoj / Re:Ako otypovať javascript?
« kdy: 07. 05. 2020, 20:24:07 »
O ničem takovém nevím, ale je to zajímavá teoretická úloha. Typová inference funguje spolehlivě s atomickými typy, ale odvození kompozice typů z literálů pro asociativní pole je netriviální (ale proveditelné).

Možno je to dobrý námet pre ročníkovú, alebo diplomovú prácu... lebo taký tool by bol veľmi užitočný a aj keby sa predával napríklad ako komerčná applikácia tak ja by som za ňu asi zaplatil.
IDE odvozování typů v JavaScriptu dělají, aby fungoval našeptávač. Ale je to dost přibližné, zejména u projektů používajících nějaký framework, který je na dynamickém typování postaven. Nemyslím si, že by bylo možné to v rámci jedné ročníkové práce nějak výrazně vylepšit.

1911
Sítě / Re:Powerline Wi-Fi do patice E27
« kdy: 06. 05. 2020, 13:41:30 »
Jak daleko od budovy je ta terasa? Ve volném prostoru se WiFi signál šíří bez problémů, takže když dáte na barák z venku nějaké UBNT NanoStation, musí vám to v pohodě pokrýt zahradu i s terasou, pokud to je opravdu zahrada a ne zámecký park…

1912
Vývoj / Re:Ako otypovať javascript?
« kdy: 06. 05. 2020, 07:32:36 »
Souhlasím s L.. – kdyby něco takového existovalo, všichni to používáme a neřešíme staticky typované jazyky.

1913
Sítě / Re:Vytvoření izolované podsítě s využitím brány
« kdy: 05. 05. 2020, 20:58:30 »
Ano, navrhl jsem několik řešení, jedno funkční (1:N PNAT), ale zároveň zjišťuji i jiná lepší (?) řešení. A zmínil jsem některé problémy, které mě při tom napadly (DHCP "relay" a )
Jak píše Mirek Prýmek – ptáte se na řešení, ale ještě jste nepopsal problém.

Vlastnosti nadřazené síte jsem myslel:
-využít bránu 192.168.1.1  k přístup na internet 192.168.1.1 Bude stačit vůbec tato jedna brána a jak se vyřeší problém s tím, že z pohledu klentů není v síti 192.168.200 ? Není i potřeba druhá brána .192.168.200.1, která bude pouze mezikrok  k 192.168.1.1
Začal bych tím, že si ujasníme některé základní pojmy. Router je zařízení, které propojuje několik sítí (alespoň dvě). Zařízení v síti komunikují s ostatními zařízeními ve stejné síti přímo, pokud chtějí komunikovat se zařízením z jiné sítě, musí komunikovat přes router. Brána je router, který vede do nějaké velké sítě – často do internetu. Takže v té vaší malé síti budete mít nejspíš jeden router, který bude na druhé straně připojený do té velké sítě 192.168.0.0/16. Tím pádem zároveň bude pro tu vaši malou síť tento router fungovat jako brána – ze vaší sítě zprostředkuje přístup do větší sítě a přes ni i do internetu.

- využití  "autoritativního" DHCP pro "lokální" DHCP - upraví odpovědi, aby maska podsítě byla 192.168.200.0/24
To je nesmysl.

1914
Netuším, co jsou „určité vlastnosti z nadřazené sítě“.

Určitě v jedné oblasti (v rámci jedné kabeláže, v propojených sítích) nechcete provozovat několik různých sítí se stejným (nebo překrývajícím se) rozsahem IP adres. Takže pokud chcete provozovat síť 192.168.200.0/24, tenhle rozsah už nikde jinde nepoužívejte. Klidně můžete mít vedle síť 192.168.0.0/17, ale nepoužívejte síť, která by se s 192.168.200.0/24 překrývala.

Takže pokud už tam máte síť 192.168.0.0/16 a nemůžete to změnit, použijte pro tu svou síť jiný rozsah, třeba něco z 10.0.0.0/8 nebo 172.16.0.0/12.

1915
Software / Re:sha512sum kontrola SeaMonkey
« kdy: 04. 05. 2020, 11:39:07 »
Nejjednodušší bude upravit ty cesty ve vašem souboru seamonkey-2.53.2.checksums (osobně si myslím, že by v tom souboru staženém z webu ty cesty být neměly, že je to chyba při vydávání Seamonkey). Nenašel jsem, že by sha512sum mělo parametr, kterým by bylo možné část cesty ignorovat.

1916
Software / Re:sha512sum kontrola SeaMonkey
« kdy: 04. 05. 2020, 11:00:01 »
Podle mne je problém v tom, že v tom souboru s checksumy je cesta k souboru včetně adresářů, ale vy máte pravděpodobně soubor uložený v aktuálním adresáři.

1917
Sítě / Re:Mikrotik - podmnozina subnet2 v subnet1
« kdy: 04. 05. 2020, 09:41:09 »
Podmnožinu sítě určitě dělat nechcete. To, co chcete, je úplně normální routování. Kdybyste měl jeden router, normálně na něm nastavíte 3 sítě – dvě lokální a jednu bránu do internetu. Vy tam z nějakého důvodu máte ještě ten druhý router – předpokládám, že je připojený k tomu prvnímu. Takže jenom na hlavním routeru nastavíte, že síť 192.168.1.0/24 je dostupná přes druhý Mikrotik. Druhý Mikrotik má předpokládám jako bránu nastavený ten hlavní router, takže tam nemusíte nastavovat nic, pakety pro 192.168.1.0/24 stejně bude směrovat na ten hlavní router.

1918
Sítě / Re:Optika do domu
« kdy: 02. 05. 2020, 11:37:45 »
Nie len mne, ale urcite kazdemu ide o to aby mal stabilne pripijenie internetu. Pod pojmom stabilne pripojenie mam na mysli, minimalne vypadky, vzdy rychli ping (na optike do 7-10 ms) a deklarovana rychlost by nemala klesnut pod 50% (cize napr. pri 300/30 by to nemalo byt pod 150/15). Urcite by mi nevadil pokles ani na 70% (nie vsak dlhodoby).
Já myslím, že marketingové kecy ve skutečnosti nikoho nezajímají. Když si zjistíte, co je to ping a co všechno může znamenat rychlost připojení, zjistíte, že ten váš text je jenom obecná mlha.

Velmi nevidim do wifi spojov PtP ale urcite su dnes na vysokej urovni a mali by fungovat bez vypadkov. Ale aj keby ISP2 mal spoj 2.5Gib full duplex do lokality kde byvam, tak kolkym klientom vie poskytnut 1000/100 Mbit ? Max 2 klientom a pri agregacii 1:50 max. 50 klientom. Ked uz ma zapojenych cez 100 klientov, tak neviem si predstavit aby som mal v spicke garantovane aspon 50/5. Ale ako som spominal, rychlost mi nevadi ci je to 100, 200, alebo 300 mi je jedno (teraz mam 40/4 a som spokojny).
A když tam těch 2,5 Gbit/s přitáhne optikou, změní se na tom co?

Agregace funguje úplně jinak, než si představujete. Pokud ISP prodá tisícovce zákazníků 1 Gbit/s, opravdu nepotřebuje 1 Tbit/s přípojku do internetu.

Pokud chcete, ISP vám rád prodá přípojku s garantovanou kapacitou jen pro vás. Ale bude to pěkně drahé.

A co sa tyka podpory zakaznikov, tak urcite ani maly ISP nechce vypadky, ale ked ich ma, tak ma vacsi problem ako velky ISP. Ked mu blesk odpali PtP spoj, tak zaplace, ale velky ISP si ani len nevsimne investiciu za 5 000-10 000€.
Myslím, že si to představujete jako Hurvínek válku. Oba dva budou mít ty spoje pojištěné proti zásahu bleskem, nebo už mají těch spojů tolik, že nemá smysl externím pojištěním rozkládat riziko a „pojistí“ si to sami.

1919
Vývoj / Re:Microservice architektura pre real-time aplikaciu
« kdy: 02. 05. 2020, 09:49:13 »
Já bych to viděl tak, že pokud chcete mít 100% spolehlivost, potřebujete distribuované transakce. A to je samostatné téma.

Pokud nechcete 100% spolehlivost, končíte s tím, že se požadavek předal systému a že máte brokera nastaveného tak, aby nic neztratil.
Distribuované transakce nezajistí 100% spolehlivost. Naopak dost zvyšují komplexnost systému. U takhle triviálního systému je jednoduchý způsob, jak zvyšovat spolehlivost – prostě přidávat další uzly a hlas považovat za zapsaný teprve tehdy, když zápis potvrdí víc uzlů.

1920
Vývoj / Re:Microservice architektura pre real-time aplikaciu
« kdy: 01. 05. 2020, 19:16:03 »
Je divné nejprve něco zapisovat do databáze a pak to odsud propagovat do fronty. Fronta se používá pro oddělení producenta a konzumenta, takže logický postup by byl opačný – zapsat do fronty, a jedním konzumentem zpráv z fronty může být i databáze.

Spring a mikroslužby nejde moc dohromady, síla Springu je naopak v tom, že můžete mít vše v jednom. Vím, že se Spring snaží tlačit i tímhle směrem, protože je to moderní, ale Spring pro to není a v nejbližší době nebude vhodný nástroj. Buď bych zvolil Spring, a pak bych se z toho nesnažil dělat za každou cenu mikroslužby, nebo bych zvolil mikroslužby, a pak bych si vybral Micronaut (já osobně), nebo třeba Helidon nebo Quarkus.

Stran: 1 ... 126 127 [128] 129 130 ... 375