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 ... 265 266 [267] 268 269 ... 375
3991
Software / Re:Informace o obrazcich z PDF
« kdy: 17. 04. 2017, 09:11:33 »
Pokud jsou to opravdu JPEGy, mohou v sobě mít EXIF data. Ovšem skenery do fotek geolokační údaje nevkládají a nedává mi žádný smysl, že by je do naskenovaných obrázků někdo vložil dodatečně.

3992
Studium a uplatnění / Re:Vypovedni lhuta a OSVC
« kdy: 16. 04. 2017, 17:41:16 »
Smluvní ujednání je platné, pokud není v rozporu se zákonem. Není pravda, že výpovědní lhůtu u smlouvy definuje jen zákoník práce pro zaměstnance. Výpovědní lhůta smlouvy je naprosto běžná věc. Máte jí u nájemní smlouvy na byt, u smlouvy se telekomunikačním operátorem – prakticky u každé smlouvy, která se uzavírá na dobu neurčitou, a i u spousty smluv, které jsou uzavřené na dobu určitou (ale je možné je vypovědět předčasně).

3993
Vývoj / Re:Java Spring - API volajici samo sebe - antipatern?
« kdy: 16. 04. 2017, 15:07:45 »
Protože co jiného by Service tvořila, než nějaké veřejné API?
Servisy tvoří především implementaci. Vedle toho mohou ale nemusí tvořit také veřejné API.

Vnitřní uzly mezi vrstvou Service a DAO, ať jsou Component.
O Component jste předtím vůbec nepsal – myslel jsem, že je zahrnujete mezi service. Každopádně ale Service a Component netvoří dvě různé vrstvy aplikace. Rozdíl mezi Service a Component je ve Springu jenom v tom, že Service se účastní transakce ale Component ne. Klidně si ale můžete nadefinovat vlastní stereotypy a ty Springovské ani nemusíte používat. A i když je použijete, Component mohou být součástí API a Service mohou být jen interní implementace. A dává smysl převolávat i služby, které jsou součástí veřejného API.

Z aplikace musí být jasně vidět její Business logika
Což ale nijak nesouvisí s tím, jak používáte Service nebo Component.

a proto to nemůžou být špagety kde Service volají jiné Service.
Píšete „ a proto“ – já tam ale žádnou souvislost nevidím.

tak si otevřu danou Service a musím ji jasně vidět jako na stříbrném podnose, na jednom místě
Přesně tak. Takže abyste mohl tu logiku jasně vidět na jednom místě (na pár řádcích kódu), musíte kód dekomponovat – z té Service, která tvoří veřejné API, budete postupně volat jednotlivé části implementace. A ty jednotlivé části mohou být další Service – ať už veřejné nebo neveřejné.

Třeba když budete vytvářet objednávku v e-shopu spolu s novou registrací uživatele. Interně zavoláte dvě služby, registraci uživatele a uložení objednávky. Obě jsou součástí veřejného API, protože můžete i zvlášť zaregistrovat uživatele (bez objednávky) a také můžete zvlášť jen uložit objednávku (pro uživatele, který už je registrován). A samotná registrace uživatele ještě bude volat další Service, ověření poštovní adresy. To může být jen interní Service, ale nakonec ji stejně asi budete chtít zveřejnit, abyste mohl validaci adresy dělat už průběžně, jak ji uživatel zadává.

3994
Vývoj / Re:Java Spring - API volajici samo sebe - antipatern?
« kdy: 15. 04. 2017, 14:40:59 »
Proč si myslíte, že by všechny služby ve Springu měly tvořit veřejné API? Podle toho vašeho návrhu by všechny služby mohly být jen primitivní, mohly by volat jen datovou vrstvu. K čemu by to bylo dobré?

3995
Vas router nevie VPN? ako ze nevie robit VPN server? alebo ze nevie presmerovat port na VPN server? Ze nevie robit VPN server je bezne- je to predsa router. Ale to ostatne musi robit z prstom v nose.
On je tu trochu zmatek v pojmech. 023514457 se ptá, zda má dát firewall před router. Ale ve skutečnosti chce vědět, zda má dát router, firewall a VPN server před WiFi AP s routerem a switchem.

3996
Chcem si rozbehat VPN pristup, DMZ + niektore dalsie veci co nepodporuje moj router. […] Kedze sa mi doma vala pfSense FW napadlo ma preco ho nevyuzit.
To máte doma tak složitou síť, že to nezvládne routovat ten pfSense FW? Nebo to „váš router“ je ve skutečnosti WiFi AP s routerem a vám jde hlavně o tu WiFi síť? Pak jednoznačně firewall před WiFi AP – jednak asi chcete mít i tu WiFi chráněnou firewallem, jednak to WiFi AP bude nejspíš nějaké levné SOHO řešení, které bude z celé vaší sítě nejspíš to nejzranitelnější zařízení. Ale počítejte pak s tím, že (pokud nenakonfigurujete firewall na tom WiFi AP routeru) vaše drátová a bezdrátová síť jsou z hlediska zabezpečení jednou sítí.


Prislo mi logicke daj najprv FW az potom router ale stretol som sa uz aj s opacnym nazorom.
Router propojuje různé sítě. Firewall chrání síť. Pokud byste tedy chtěl mít firewally až za routerem, musel byste jich mít několik – pro každou síť jeden.

3997
První určitě firewall, aby byl chráněn i ten router. Akorát je trochu zvláštní, že umíte nakonfigurovat firewall, a přitom se musíte na tohle ptát. A mít pro domácí síť zvlášť firewall a zvlášť router je také dost výjimečné.

3998
Sítě / Re:význam silnějších AP
« kdy: 01. 04. 2017, 10:38:55 »
Anténa neslouží jen jako vysílač, ale také jako přijímač. Tj. citlivější anténa bude schopna zachytit slabý signál mobilu  i tam, kde by už méně citlivá anténa nic nezachytila (resp. by to bylo pod hranicí rozlišitelnosti od šumu). To znamená, že dává smysl mít na každé straně jinak „silnou“ anténu. To samé máte třeba u GSM – porovnejte si anténu, kterou máte v mobilu, a anténu, která je na vysílacím stožáru základnové stanice.

Jak píše kolega, je také dobré myslet na to, abyste zbytečně nerušil okolí, když tam dosah toho signálu nikdy nevyužijete. Jaký je rozdíl v dosahu signálu byste se měl u těch zařízení dozvědět (od výrobce nebo od slušného prodejce), zařídil bych se podle toho. Resp. jinak – pokud chcete pokrývat malý byt, nedává výkonnější anténa žádný smysl. Pokud chcete pokrýt dům s přilehlou zahradou, nejspíš to využijete.

3999
Server / Re:Deduplikace záloh
« kdy: 29. 03. 2017, 16:24:39 »
Neexistuje nějaký souborový systém podobný taru
Co myslíte tím „podobný taru“? Aby v něm soubory nebyly ukládané v sektorech, ale za sebou? To je třeba ISO 9660, který se používá na CD, případně ještě novější UDF (i když ten je o něco komplikovanější).

který je možné bzipovat?
Opět nevím, co tím myslíte? Máte souborový systém v souboru připojený přes loopback? Bzipovat můžete jakýkoli soubor. Nebo by podporu bzipování měl mít v sobě přímo ten souborový systém?

Možná by bylo jednodušší, kdybyste napsal, co vlastně chcete řešit.

4000
Software / Re:Zasifrovani souboru bez klice
« kdy: 28. 03. 2017, 21:32:52 »
To je normální asymetrická kryptografie nebo kryptografie veřejného klíče. Když se něco posílá šifrovaným e-mailem, posílá se to přesně takhle. Pro šifrování se použije veřejný klíč, zašifrovat jím může kdokoli. Dešifrovat to může jenom vlastník privátního klíče.

Existují dvě nejpoužívanější technologie – hackerská technologie PGP, ale technologie podle IETF standardů PKCS (pro šifrování dříve S/MIME, novější CMS). K tomu prvnímu potřebujete buď originální PGP nebo GNU implementaci GPG, pro PKCS můžete použít např. OpenSSL.

4001
Server / Re:Deduplikace záloh
« kdy: 28. 03. 2017, 13:22:42 »
Moment -- myslel jsem, ze u rdiff-backup mam zalohu taky rovnou jako citelne soubory na disku. Pletu se? Hodlam na to prejit.
Pletete se, v čitelné podobě je na disku jenom poslední záloha, starší se musí „zrekonstruovat“ z rozdílových souborů. Pomocí FUSE se ta rekonstrukce dá schovat za běžné rozhraní souborového systému, ale na pozadí pořád bude muset ovladač tu rekonstrukci provést.

Doporučuju k přečtení Záloha dat pomocí rdiff-backup.

4002
Server / Re:Deduplikace záloh
« kdy: 27. 03. 2017, 15:43:39 »
zfs/brtfs deduplikace online by byla fajn, ale co jsem pochopil, tak to docela žere zdroje (RAM a to jakože dost).
Takhle se bude chovat každá deduplikace – potřebujete mít nějaké kontrolní součty všech zapsaných bloků a umět v nich rychle vyhledávat. Aby to dávalo smysl, je potřeba je držet v RAM.

V případě btrfs nemusíte používat on-line deduplikaci, můžete porovnávat jen vybrané soubory (třeba novou a předchozí zálohu), čímž zdroje výrazně ušetříte. A dostanete tím prakticky to, co dělají zbackup.org nebo rdiff-backup, akorát to máte rovnou jako čitelné soubory na disku.

4003
Server / Re:Deduplikace záloh
« kdy: 27. 03. 2017, 14:11:12 »
Nemůžete dělat deduplikaci (pomocí hardlinků) obecně na libovolném systému a s libovolnými nástroji. Snadno se vám pak stane, že zjistíte duplicitu mezi dvěma soubory, nahradíte je hardlinkem – pak někdo jeden z těch souborů změní, a tím vám zároveň změní i ten druhý. Pokud tedy ten disk používáte jenom pro zálohy, pořád byste je musel dělat tak, že každý den vytvoříte komplet novou zálohu, a teprve po té uděláte deduplikaci – tj. nesměl byste zálohy přepisovat. Ale pokud používáte NFS/Sambu a ne rsync, zřejmě už to tak děláte dnes.

Proč nepoužijete btrfs?

4004
Vývoj / Re:Detekce letního času
« kdy: 26. 03. 2017, 08:40:28 »
Zarizeni, ktere se syncuje proti timeserveru a nezna casove zony, bude jednoduse porad zobrazovat UTC.
Jenže já jsem nepsal o tom, že nezná časové zóny, ale že neumí přepínat SEČ a SELČ. Vyřešit, že je v zóně +01:00, je mnohem snazší úkol, než řešit databázi časových zón a přepínání na letní čas a zpět.

4005
Vývoj / Re:Detekce letního času
« kdy: 25. 03. 2017, 22:46:31 »
My o tom kramu nic nevime
V takovém případě mi připadá rozumné řešit problém, který popsal Prezek, který o tom „krámu“ asi něco ví, a neřešit něco úplně jiného.

asi neumi sam sebe synchronizovat podle timeserveru
Nevím, z čeho tak soudíte. Zařízení, které bude synchronizovat svůj čas v UTC podle timeserveru (nebo jakéhokoli jiného rozumného časového normálu), ale nebude umět přepínat časové zóny podle přechodů mezi SEČ a SELČ, se bude chovat přesně tak, jak popisuje Prezek. Bude mít přesný čas, ale nebude ho umět zobrazit lidem ve formě, kterou očekávají.

Stran: 1 ... 265 266 [267] 268 269 ... 375