ntdrt

Trochu zavádějící, prý to umí skenovat mojí síť, tak jsem dal scan a nenašlo to ani jedno zařízení. Ani ty co nemaj firewall...

 

Lokaci to určilo blbě, asi podle IP

 

U strašně moc věcí je řešením, že nemáš používat JavaScript... To by mě potom 75% webů vůbec nefungovalo

Pro mě není důležité, zda hraju hry na ultra či high settings. Jde mě spíše o nejlepší poměr cena/výkon. Pokud ta karta zvládne většinu her na 1080 důstojně, tak za mě dobrý. O bazaru neuvažuju. Chci si koupit novou věc, co je pěkně shiny .

 

Nová GTX980 se dá koupit od 10 tisíc, GTX980Ti od 12 tisíc, GTX1070 za 12,5 tisíců. GTX1060 je dneska na Alze za 7,7k (pouze jeden model ale co, i to se počítá), což se rovná ceně RX480.

 

Z tý první kategorie se mě zdá nejvýhodnější GTX1070, ač nevím, zda je to nutné, za ten příplatek tolik výkonu nedostaneš. Tudíž podle dnešních cen jsou GTX1060 a RX480 nejvýhodnější karty? Ač RX480 má problém, že neexistujou verze s lepším chlazením. A GTX1060 má zase problém, že ty nepředražený verze sou většinou vyprodaný a sou na skladech jen ty nesmyslný verze za 10 tisíc. To ve mě evokuje, že bych měl čekat .

Jakou kartu by si zvolil na 1080p? Vyplatí se vůbec dneska kupovat grafickou kartu? Ten trh je takovej divnej, spousta novejch karet co nejsou skladem... Či GTX1060 za 10 tisíc

V bezpečnosti nemůžeš bejt optimista "nebudu tam dávat heslo, však na tu stránku stejně nikdo nepůjde"

V tom případě to je blbé . A tvoje situace je bez řešení. Ať vymyslíš cokoliv, tak skončíš u toho, že musíš mít něco, co prokazuje identitu a musíš tomu věřit. V tomhle případě se tomu nedá věřit a můžeš tedy jen doufat.

 

Minimalizace teoretického dopadu je určitě dobrá cesta - nepoužívat globální přístupy, ale přístup pro každé zařízení izolovat. Potom bude paseka menší.

Ale tím si přece vůbec nepomůžeš. Princip autentizace je, že ty máš něco, co prokazuje tvojí identitu, je irelevantní co to je, je to klíč, je to jméno+heslo či TLS certifikát. Výsledek je stejný - autentizační údaje musíš někde uložit a to někde bude paměť daného zařízení. Hackerovi je úplně fuk, zda má extrahovat z flashe certifikát či heslo. Jo, certifikát mu zabere o 10 minut déle, ale přístup získá tak i tak.

 

BTW: máš pravdu, že klientský certifikát se běžně nepoužívá, tento fakt ti ale nijak nepomůže. Nesoustřeď se na to co umí FileZilla, protože to není důležité, zkus si přečíst to ostatní, protože to je důležité pochopit.

 

Já jsem přesně pochopil na co ses ptal a dal jsem ti validní odpověď. Ty se ptáš co si máš vybrat, já ti říkám, že si máš vybrat co chceš, protože všechny možnosti jsou stejně špatné. Řešení je neukládat autentizační údaje do zařízení, ale do hlavy uživatelů.

Nezáleží na tom jaký druh FTP autentizace použiješ (ani jaký protokol použiješ), pokud chceš mít autentizaci hard-coded, tak použij co chceš, vše totiž vyjde bezpečnostně na stejno - pokud útočník získá zařízení, tak máš díru jako vrata. Jinak FileZilla (a ostatní FTPS klienti) samozřejmě certifikáty umí. FTPS bez certifikátů je totiž FTP (co umí či neumí FileZilla není důležitý faktor v této diskuzi).

 

Normálně máš anti-temper switche. Pokud kdokoliv neautorizovaný otevře zařízení, zašifrovaný klíč se smaže. Pokud by si anti-temper dokázal obejít, tak chip hlídá sám sebe, pokud ztratí napájení, smaže se, pokud změníš jakoukoliv proměnnou (změníš napětí, snažíš se přistoupit na k datům, ...) smaže se. Někdy celou sekci zalejou do epoxy. Tyhle microcontrollery jsou speciálně navržený a certifikovaný na tyhle aplikace. Ač to samozřejmě stojí nějaký $$$.

 

Touhle cestou nikdy jít nechceš a pokud je šance, tak použij jiný typ autentizace - požaduj uživatelský vstup a tvůj server udělí oprávnění na základě toho, jaké autentizační údaje daný uživatel poskytne - potom nebudeš mít hard-coded žádné autentizační údaje a vůbec tě nezajímá, pokud někdo zařízení získá a stáhne si z něho firmware/paměť. Protože zařízení/firmware nebude mít sám o sobě žádná oprávnění. Pokud nemůžeš požadovat uživ. vstup, tak máš problém. Budeš muset počítat s tím, že kdo získá fyzický přístup k zařízení, ten získá přístup k tvému serveru. Budeš spoléhat na to, že to uživatele nenapadne či nebude mít dostatečný znalosti.

Web za firewallem a přístup jen přes VPN je to nejlepší, co můžeš udělat. Pokud útočník získá přístup k počítači s VPN, ukradne certifikáty a následně uhádne passphrase, tak to je už tak pokročilej útok, že nedává smysl se tomu bránit, ne u normálních systémů (nedává smysl investovat do zabezpečení více, než je hodnota samotnýho systému/informací/produktu). Samozřejmě PC s VPN nesmí být veřejně dostupný a musí být rozumně zabezpečen.

 

Útočník pak musí být někdo z tvejch vlastních lidí a tomu nezabráníš nikdy.

Framework ti určitě může pomoci. Nette dokáže řešit XSS i SQL injection za tebe, pokud to použiješ správně. Určitě nestačí to brát tak, že používám framework XY a tím jsem v pohodě. Musíš vědět oč jde, pokud nad tím nebudeš přemýšlet, tak bezpečnostní díru udělat můžeš, ať bude framework/knihovna sebelepší. Nástroj ti může pomoci, ale rozhodně nemůže předejít tomu, že napíšeš blbost, která daný mechanismus zabezpečení znehodnotí.

 

Formuláře by si měl určitě řešit, pokud by šlo o Nette a presentery, tak presenter má metodu checkRequirements($element), která se zavolá jako první věc v presenteru, tím pádem řeš zabezpečení tady. Pokud nepoužíváš výchozí funkcionalitu, což nejspíše nebudeš, tak jí přepiš (poděděním samozřejmě) a nahraď za svojí logiku, svoje podmínky, svůj systém oprávnění/rolí/uživatelů. Metoda checkRequirements($element) se zavolá pro každý požadavek jako první, tudíž to platí pro action/render/pohled i pro formuláře a vnořený komponenty, zkrátka v této metodě můžeš pokrýt kompletní zabezpečení presenteru, vše na jednom místě.

Stačí logicky přemýšlet. Nejčastější díry spočívaj v SQL injection a XSS, to určitě znáš, pokud ne, tak si to můžeš vygooglovat. Další chyby jsou logickýho rázu - napíšeš jednoduše blbost. Napsat blbě se dá v podstatě cokoliv... V tomhle ohledu nelze moc poradit, nepiš blbosti . Pokud jde o oprávnění uživatelů, tak tomu věnuj větší pozornost, projdi si kód několikrát, zamysli se nad tím.

 

Učit se bezpečnost stylem pokus/omyl nechceš, za to by ti klient nepoděkoval. Naučit se to můžeš tak jako vše ostatní - zajímej se o to a přemýšlej nad tím. Můžeš číst články, můžeš sledovat obecný dění v IT (a učit se z chyb druhých) či třeba sledovat lidi na twitteru (např. https://twitter.com/spazef0rze).

 

Například v tvé první otázce si přemýšlel správně, měl si daný problém a našel si cestu, jak by to šlo obejít - pokud takovou cestu najdeš, tak si polož otázku, jak tomu lze předejít a pokud to je proveditelné, tak to udělej.

Vůbec neřeš, jak moc obtížný je zabezpečení obejít, vždy to musíš udělat takovým způsobem, aby to z principu nešlo obejít, za žádných okolností. Systém by měl být zabezpečen tak, že ani autor, který má zdrojáky v ruce a zná každý řádek, nedokáže zabezpečení prolomit.

 

Tudíž ano, vždy ověřuj, zda má uživatel právo udělat konkrétní akci. A to neplatí jen pro akce dostupný z URL ale taky pro formuláře, ty musíš systém navrhnout takovým způsobem, aby nešlo odeslat formulář bez požadovaných oprávnění. Útočník totiž vůbec nemusí použít tvoje UI, tvoje odkazy, tvoje formuláře, on pošle POST/GET požadavek přímo a tudíž ověření musí být vždy součástí dané akce.

 

Stejný pravidlo by si měl použít i pro komunikaci mobilní/externí aplikace <-> server. Pokud navrhuješ API, tak určitě neřeš oprávnění na straně mobilní/externí aplikace, ale na straně serveru. Udělat reverzní inženýrství aplikace, či aplikaci cracknout není žádný problém a pokud by oprávnění řešila aplikace a ne server, tak útočník automaticky dostane přístup k celému systému. Nezáleží, zda je externí aplikace v binární formě.

 

Nikdy nevíš, kde ve finále tvůj systém skončí, jak se bude rozvíjet, či kolik lidí bude chtít danej projekt poškodit. Tudíž musíš ošetřit i útoky, který pravděpodobně nikdy nevzniknou.

Nehrab se v ovladačích, pokud to funguje. Maximálně stáhni nejnovější ovladače pro grafiku (z nvidia/amd.com). Zbytek ovladačů nech být, pokud to funguje/je to stabilní. Na USB/chipsetu/síťový kartě a já nevím na čem ještě, nemáš co vylepšovat, můžeš to akorát rozbít .

 

A platit za nějakej náhodnej vyhledávač, co instaluje bůh ví co... To určitě ne. Když už, tak si najdi stabilní verzi ovladačů z oficiálních stránek a neinstaluj náhodný verze, co najdeš na netu.

ORM je v PHP stejně tak dlouho, jako je v .NET. Doctrine september 2008. Entity framework august 2008. Což se okopírovalo z Javy - Hibernate 2001. Není to nic speciálního, i blbej JavaScript má ORM .

 

Jinak na složitý selecty se ORM vůbec nehodí. Máš sice krásný API, ale to v pozadí generuje pěkný hovadiny a musíš se hodně snažit, aby framework pokládal optimalizovaný dotazy. ORM je určený hlavně na tuctový CRUD aplikace. Kde se operace pořád dokola opakujou. Ne na projekty, kde budeš mít v podstatě pár super-selectů. Tam ti to práci jen přidělá a mapping na entity ani neoceníš.

 

--

 

Jinak velký tabulky nejsou problém, databáze sou navržený (MySQL, MS SQL Server, Postgres, cokoliv co si vybereš), aby zvládaly miliony a miliony záznamů v jedný tabulce. Stovky milionů řádků není problém. V tomhle případě je klíčem optimalizace a využívání indexů. Pokud budeš vyhledávat podle sloupců, který maj index a datový set hned omezíš, tak není problém, aby ti MySQL vrátil subset dat do pár ms i když bude tabulka gigantická. MySQL zvládá při správném zacházení i miliardy záznamů v jedný tabulce.

V tomhle případě může kešovat jenom server. Kešovat POST je hodně velká blbost, takže server by kešovat určitě neměl. Na straně androidu keš není, jednak to ta primitivní knihovna snad ani nepodporuje, nedává smysl aby to podporovala a navíc jdou requesty ze dvou zařízení - i kdyby keš byla, tak by to nevadilo, protože jedno zařízení nevidí keš druhýho zařízení.

 

Takže já bych řek, že je špatně nastavený IIS, kešuje nesmyslně POST požadavky (takže to není man-in-the-middle) a tím pádem když se zeptá další připojení, tak prostě šáhne do paměti a webová aplikace nepřijde ani na řadu. IIS tuhle funkčnost má, má output cache, tj. výstup z PHP/ASP/whatever se ukládá do ramek viz http://www.iis.net/learn/manage/managing-performance-settings/configure-iis-7-output-caching

Java to neumí. Volat this.neco nedává smysl, protože this je aktuální instanace (což je samozřejmě dítě). Stejně jako existuje ukazatel na instanci rodiče "super", by si potřeboval ukazatel něco jako "current". To ale neexistuje.

 

Řešení je jednoduchý. V předkovi implementuj další privátní metodu a tam dej tu funkčnost. Tj. třeba metoda saySomething(), tu použiješ v toString() i v konstruktoru. Tím pádem když přetěžíš toString, tak přetěžuješ pouze volání původní logiky a ne logiku samotnou.

Tak to očividně nebude výkon -> bude chyba nejspíš ve software -> zkus jiný media server. Ale tady se stejně jedná o realtime vkládání titulků do obrazu, což je brutálně náročný na výkon, vůbec bych se nedivil, kdyby to slabý CPU nedokázal generovat v rozumným čase. Já původně předpokládal, že všechny DLNA zařízení podporujou textový titulky.

 

A pokud si to vygoogluješ, tak první co najdeš "Some devices do not have any support for subtitles and require them to be burned into the video stream (hardsubs), thus effectively transcoding the video with the text on the screen."

 

A následně "Note, that when burning subtitles in the stream are enabled, you might experience high CPU usage and possibly playback issues (depending on your hardware). This method is not suitable for low powered NAS devices."

 

http://serviio.org/i...w=article&id=33

 

Takže bych to viděl asi takto: NAS to neutáhne a tvůj test na desktop CPU selhal jiným způsobem.

No, to vypadá jako zásadní problém... Ten NAS má koneckonců nějakej arm o 400mhz a podobě, takže pokud je třeba vkládat titulky do obrazu, což očividně plex dělá, tak na to ten malej arm nebude mít dost koňů.

 

Řešení? Pořiď si server a používej NAS jen jako storage.

Právě jsem napsal dlouhý text, kde jsem všechno vysvětlil a prohlížeč se to rozhodl smazat, nebudu to psát znovu .

 

Takže TL;DR:

To o čem mluvíš je technologický dluh. Pointa je tomu předejít a už od začátku prezentovat workaround jako špatné, strašně špatné řešení, vysvětlit proč je to špatný a že to má katastrofický dopad na budoucnost - vedení nesmí brát patlání jako styl vývoje, musí vědět, že patlání je špatný a musí tomu za každou cenu zabránit. Pokud už máš obrovský technologický dluh, tak jo, jediná cesta je totální refactoring a to vedení nikdy neschválí. Navíc v tudle chvíli je patlání standard, takže těžko přesvědčíš vedení, že je to špatná věc.

 

U GITu (i Mercurialu) se vždy pracuje s centrálním repositářem. Vývojář komunikuje pouze z tímto repositářem - není běžně, aby probíhala synchronizace mezi vývojáři přímo. Tím pádem v centrálním repu jsou vždy všechny nejnovější změny a release se dělá z toho repa. Centrální repo je většinou někde na serveru (firemní server, bitbucket, github, ...).

 

Takže praxe:

• každý vývojář si udělá klon centrálního repa
  
• vývojáři dělají změny, tyto změny commitují do svého lokální repa (toho klonu)
  
• vývojáři pushují změny do centrálního repa
  
• vývojáři pullují změny z centrálního repa
  

Při pullu git provádí merge (v případě, že centrální repo má nové změny, který můj klon nezná a já zároveň nějaké ty změny udělal také). Při mergi může vzniknout konflikt - upravím stejný soubor na stejném řádku atp., to se potom musí řešit ručně. Lze tomu předejít pomocí rebase (git pull --rebase), což v mnoha případech mergi předejde (tím pádem i potenciálním konfliktům) - tady je hlavní commitovat změny v co největším rozlišení, nedělat obrovský mix-balíky "změny za pátek" no a to je asi vše.

To je vážně ta bedna tolik počmáraná? Až na ty nálepky je to decentní sestava, pokud by sis skládal něco sám, ve výsledku by si měl něco hodně podobnýho. Cena bude samozřejmě větší, než cena surových komponent, nicméně to musíš brát tak, že by si to PC musel sestavit, nastavit, zprovoznit, nainstalovat a to ve výsledku pár hodin zabere a pokud nejseš vyloženě nadšenec, co si výběr komponent a skládání PC užívá, tak nevidím důvod, proč si nekoupit hotovou sestavu.

 

Takže pokud vyloženě nechceš dělat tanečky okolo, klidně si tuhle sestavu kup, kombinace HW je dobrá, ta cena není nijak přemrštěná, nevidím žádnej problém.

V tom případě používáš SVN "jako Git" a vůbec nepoužíváš ten centrální locking, což je hlavní feature SVN. Mercurial či git dokáže to samé, co píšeš... Commitneš změny, pullneš, vyřešíš kolize, který nejdou automatizovat a commitneš (+ pushnes). Git má k tomu rebase - což dokáže předejít v mnoha případech mergování - tím pádem se vyhneš konfliktům - změny se porovnávaj na úrovni commitů a ne jako celek.

 

Tudíž tak trochu nechápu, proč se ti Git nezdá, v principu dostaneš naprosto stejnou věc, jen používáš trochu jiné API příkazů. S rebase dostaneš dokonce vylepšení.

 

Mimochodem... To, že má soubor 5000 řádků (resp. ještě víc), je prasárna a určitě je zde místo pro optimalizaci a rozdělení této funkčnosti do menších logikých bloků... Netuším, jak je tohle v C běžný, ale v jinym jazyku by ti za to každej senior zlámal ruce (tím mluvím o C++, C#, Java, PHP, ...). Tady nejde jen o verzování, ale hlavně o správu kódu, pokud máš v souboru 10 tisíc řádků, tak je vážně náročný se orientovat, nehledě na to, že pracovat s takovým souborem je náročné i pro IDE. Ale pokud opravdu není jiná cesta, než mít v souboru 5000 řádků a více, tak máš před sebou naprostej edge-case, tudíž ignoruj co říkám, protože na tebe "drtivá většina" neplatí, ty seš totiž v té menšině. A v tomto případě se nedívej na to co říkaj ostatní, protože ty máš před sebou něco, co většina lidí neřeší a jejich řešení ti nebude na tvůj use-case pasovat. Každopádně si nemyslím, že tohle je ten případ, ale když jo, tak budiž.

 

BTW: jak mám vědět, že ta věc je nepodstatná? Reaguji na to co píšeš, netuším, co je pro tebe podstatné a co je pro tebe nepodstatné... Moje telepatické schopnosti nemají takovou úroveň, prozatím.

U drtivé většiny projektů nebude 7 lidí dělat jednu a tu samou věc a i v případě SVN to nejde, protože pokud pracuje na souboru kolega, je locked a já můžu jen čekat... Takže ten scénář nedává vůbec smysl. 7 lidí bude pracovat na různých problémech, takže přímo nezávisíš na aktuální práci kolegy, neděláte tu samou věc, tudíž nepotřebuješ synchronizaci. Pepovi co dělá faktury je naprosto buřt, že Franta zrovna dal tlačítku hezčí ikonku.

Zajímal by mě účel tohoto příspěvku ...

 

Rozhodně nedává smysl porovnávat SVN s Gitem a Mercurialem, protože to sou dvě různé věci a používají se na různých místech. Git a Mercurial jsou zase dvě skoro stejné věci, rozdíly nejsou tak podstatné, takže ve finále rozhodují hlavně osobní preference či konkrétní use-case (resp. edge-case).

 

Potřebuješ centralizovaný systém? SVN... Solidní volba. Nepotřebuješ nutně centralizovaný systém (drtivá větší případů) použij Git či Mercurial, vyber ten, který se ti více líbí, s kterým máš zkušenosti. Nevíš který vybrat? Ber git, je obecně rozšířenější a lehčeji budeš řešit případné problémy. A víc vlastně řešit nemusíš... Pokud potřebuješ vysvětlení či argumenty k těmto tvrzení, tak si zadej do google "svn vs git" či například "git vs mercurial", na stackoverflow se tohle řešilo už tolikrát a je tam tolik odpovědí a tolik lidí psalo svoje vlastní názory, že už není v podstatě co dodat.

Pokud by si neměl dostatečnou rychlost, tak by si to přehrál, ale spíš by si měl nepoužitelnej framerate a podobně. A jelikož máš 100mbit linku, resp. síťovku, tak můžeš mít až 100mega bitrate, běžný 1080p mkv má třeba 5 - 10mega bitrate, tudíž máš mnohem víc, než potřebuješ. Problém bude nejspíše na straně tvého DLNA media serveru, těžko říct co... Zkus projít logy... To bude hodně záležet na software a konfiguraci.

 

Já aktuálně používám Kodi na linux boxu a jsem naprosto spokojenej, stahovat titulky z TV pomocí jednoho kliku, moci přehrávat cokoliv co je na síti, možnost přehrávat všechny různý streamy, ... To se obávám, že žadná "smart" tv netrumfne, takže pokud chceš vážně "smart" televizi, tak potřebuješ kodi .

Jasně, jsou to trochu jiný věci, ale potřeba pro princip SVN je dneska mizivá. Proto vidíš všude git, git, git, git, git, git, git . Taky záleží na tom jakej vývojář seš, mě nevadí se přeučovat na novou věc, pokud to má smysl. Nicméně existují lidi, co nemají rádi změny, nesnášejí to dobře, takže radši zůstanou s tím, co umí, než investovat čas a snažit se přejít - takže to chápu.

SVN není moje silná stránka a díky bohu za to. Jinak eclipse to možná dělá proto, že u SVN je relativně dost práce takovou maličkost řešit, u gitu prostě má každej vývojář globální gitignore + v projektu je lokální gitignore a prostě jsou na to všichni zvyklý, takže nepřipadá k úvahu, aby ti na tyhle soubory šahalo IDE. U gitu/mercuialu máš soubor, blacklist, kterej se automaticky respektuje a daný položky prostě neexistujou.

 

SVN tohle očividně nemá, ale je tady workaround, že si ty položky dáš taky do souboru, jako normálně, jen to musíš "aplikovat" přes ten příkaz, co si ty sám psal, to by si měl udělal předtím, než to commitneš/pushneš - http://stackoverflow.com/a/17302297 snad to stačí nastavit jednou a SVN si to zapamatuje, ale netuším, nemám zájem tuhle mrtvou technologii dále zkoumat.