Příspěvky

151

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 20:09:19 »

Žádné zjišťování volného místa jako malloc(), žádný zámek, jako při přístupu ke globální haldě

Jen řeknu, že v trochu pokročilých c++ programech se malloc / global new používá jen opravdu pro objekty s dlouhou životnosti. Tam kde je trochu známý vzorec alokací, tam se používá něco rychlejšího.

Ve svých programech mám poolalloc - lockless rychlá alokace objektů s předem daného poolu. Nebo používám známý alokátor malých objektů od Andrei Alexandrescu. Všechny tyhle custom alokátory se často s výhodou realizují per thread bez zámků a v přiděleném bloku paměti a do globální haldy se chodí minimálně. A to jsem při nedávných testech zjišťoval, že optimalizace alokací probíhá i na úrovni OS a překladačů v C++. Třeba v posledních verzích MSVC je celkem obtížné napsat alokátor, který by konkuroval jejich implementaci new/malloc (testováno v praxi) - s výjimkou těch pro specifické použití.

Tak jako probíhá vývoj strategií GC, probíhá vývoj i tam kde se GC nepoužívá.

152

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 18:55:46 »

Chybou bylo, že proměnná b nebyla inicializovaná

A to mi neříkej, že tě překladač nevaroval, že testuješ hodnotu neinicializované proměnné.

No... nevaroval. Ono to bylo složitější. Překladač neumí vždy zjistit všechny okolnosti, někdy stačí, když ta proměnná je předávána do funkce referenci a v tu chvíli se tohle varovaní neobjeví. Nechci zabíhat do detailů

153

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 14:00:47 »

Ake datove typy su ten flag a b? A teda v com bol problem?

b je bool, flag byl int

problem byl v tom, že překladač předpokládá, že boolean je reprezentován jako true=1, false=0. Výše uvedený zápis se tedy v optimalizované verzi na úrovni -O3 vůbec nepřeložil, v kódu byl na tom místě obyčejný mov proměnné do proměnné. Což je v pořádku, pokud je opravdu dodrženo výše zmíněné kódování. Jenže proměnná b neobsahovala 1 jako true, ale číslo 52. Při testu if (b) to pořád funguje správně (testuje se na nulu). Ale operátor ?: už dopadl špatně díky jeho nepřeložení... Chybou bylo, že proměnná b nebyla inicializovaná

154

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 04. 08. 2015, 23:29:41 »

Chces vydelat prachy? Java

Chces si honit brko ve sklepe pred ostatnima zombikama? Instrukce

Umět assembler je dobré aspoň pasivně. Onehdy jsem řešil, jak tento kód

Kód: [Vybrat]

flag = (b==true?1:0)

může způsobit, že v proměnné flag bude číslo 52 (GCC 4.

Až průzkumem přeloženého kódu na úrovni -O3 jsem zjistil, v čem je zakopanej pes.

155

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 04. 08. 2015, 21:42:44 »

Co je velkej projekt. Předně bych velký projekt rozdělil na malé projekty. Já mám (pod správou) třeba hodně věcí v C++, zpravidla servery. Aplikace jsou v Javě, v Objective C (hádejte které), ale na serverech se používá i PHP. Na webovkách javascript. Jedna komponenta je napsaná v C#

156

O serveru Root.cz / Re:Lišta o blokování reklamy

« kdy: 24. 07. 2015, 12:16:01 »

Zaveďte platbu za obsah bez reklamy bitcoinama a já to klidně budu pravidelně platit

157

O serveru Root.cz / Re:Myslí iinfo/root.cz tento barevný reklamní cirkus opravdu vážně?

« kdy: 24. 07. 2015, 12:13:07 »

AdBlock to fixnul 

158

Vývoj / Re:SHA 512 dostačující?

« kdy: 10. 07. 2015, 10:43:37 »

Mě to připadá jako totálně mimo původní otázku.

S veřejného klíče a mého soukromého klíče spočítám jednorázové heslo

Nesmysl. Kdyby se pro vytvoření jednorázového hesla použily údaje z veřejného a soukromého klíče, tak to jednorázové heslo nebude jednorázové, protože k němu dojdu při každém použití. To jednorázové heslo (přesněji, jednorázový klíč, ephemeral key) se generuje náhodně pro každé použití znovu, díky tomu je právě zajištěna ta jednorázovost.

tak že obě čísla vynásobím přes násobení nad eliptickou křivkou.

Doporučuju pořádně přečíst celý text a nevytrhávat věty z kontextu. Soukromý klíč si nejprve vygenerujete tak, že si "hodíte kostkou" ideálně za pomocí kryptograficky bezpečného generátoru náhodných čísel. Soukromý a veřejný klíč v ECDH totiž se nevážou k osobám, jejich pojmenování je dáno čistě podle účelu. Soukromý klíč si nechávám, veřejný klíč posílám po síti, protože sít může číst kdokoliv, je takový klíč veřejný. V každém případě musí být pokaždý náhodny. ČTĚTE TO CELÉ, JÁ TO TAM PSAL!

Operace násobení není nad eliptickou křivkou zavedena. K dispozici je pouze operace sčítání dvou bodů, pomocí které lze realizovat i násobení bodu přirozeným číslem.

Opět zase nečtete nebo záměrně se snažíte příspěvek shodit tím, že zamlžujete reality. Soukromý klíč je přirozené číslo, Veřejný klíč je bod na křivce. Operace násobení je tedy realizována jako násobení přirozeného čísla bodem. Jelikož násobení je definováno jako sčítání resp. přesněji, sčítání a násobení 2x, které je realizované jako sčítání sebou sama, nepovažoval jsem za důležité takto zabíhat do detailů, protože je na to v patřičné knihovně funkce.

"Úplně postačí" skoro zní, jako kdyby to bylo nějaké základní řešení pro obyčejné uživatele s nevyřčeným dovětkem, že bezpečnostně zaměřený uživatel samozřejmě zvolí víc, protože čím víc bitů, tím větší bezpečnost
...

Úplně postačí, když přestanete blbě žvanit a trolovat.

Vezmu podepsaný dokument. Vyměním. ? ? ?. Success! :-)

Ještě tam bylo slovo ověřit

159

Vývoj / Re:SHA 512 dostačující?

« kdy: 10. 07. 2015, 01:00:15 »

K původní otázce.

Na šifrování by mělo stačit ECDH. Iniciator si hodí kostkou (silně doporučuju SecureRandom) a vyrobí si privátní klíč. Z toho si spočítá veřejný klíč. Pote pošle veřejný klíč na druhou stranu. Druhá strana udělá totéž a také pošle svůj veřejný klíč. S veřejného klíče a mého soukromého klíče spočítám jednorázové heslo tak že obě čísla vynásobím přes násobení nad eliptickou křivkou. Výsledný bod mohu eště třeba zahashovat, každopádně totéž musí udělat druhá strana. Výsledný hash je pak "heslo" do AES šifry. To je celé, není třeba nad čímkoliv uvažovat.

Úplně postačí 256 bitové křivky a 256 bitové hashe.

Pokud stavíte nad bitcoinem, patřičné funkce najdete v každé bitcoinové knihovně, i v té javascriptové.

To co jsem popsal je jen sestavení šifrovaného kanálu. Ověření důvěryhodnosti obou stran, tedy, že si povídáte s tím s kým si chcete povídat je třeba dělat mimo tento mechanismus a vůbec nesouvisí se šifrováním. Stačí si třeba navzájem vyměnit podepsané dokumenty .... tedy certifikáty, které lze posléze přímo nebo nějak transitivně ověřit.

160

Vývoj / Re:SHA 512 dostačující?

« kdy: 10. 07. 2015, 00:41:50 »

Náhodou, dlouhé heslo si zapamatuju

https://www.youtube.com/watch?v=SH1Ju_WFWzs

161

Hardware / Re:Android s QWERTY klávesnicí

« kdy: 11. 05. 2015, 12:53:51 »

LG Optimus F3Q z USA.

Může vám dorazit zamknutý (dá se odemknout)

Ale každopádně 3G sítě jen ve městě a na LTE zapomeňte

162

Server / Re:MySQL server je pomalejsi na silnejsim serveru

« kdy: 06. 05. 2015, 14:12:21 »

Speciálně pro MySQL doporučuju velké množství INSERTů a UPDATEů sloučit do co největších transakcí. Výkon vzroste násobně. Má vlastní zkušenost, kvůli velkému počtu nahodilých zápisů jsem na jednom serveru speciálně psal kolektor, který všechny zápisy od různých zdrojů/uživatelů posbíral během dvousekundového okna a pak je jednorázově provedl a commitnul. Mezitim se v jiném dvousekundovém okně sbíraly další zápisy. Nevýhodou bylo, že data se do databáze reálně zapsala až po 2 - 4 sekundách po vykonání příkazu. Protože jsme ale stejně replikovali, frontend s tím počítal.

163

Software / Re:Bezpečný filesystem pre flash

« kdy: 22. 04. 2015, 09:48:06 »

Viz jarda, nenavysis ani po pid, flashdisky vubec wearleveling neresej. Musel by sis to resit sam v ramci FS. A k tomu bys musel jeste navic vedet, jak je fyzicky ta pamet organizovana, coz v 99,99% vedet nebudes.

To si myslím, že není úplně pravda. I flashky řeší wearleveling, jako SSD, jen jinak, zpravidla jinou strategií a důležitým hlediskem je v tomto případě rychlost kvůli celkové pomalosti a jednoduchosti řadiče. Proto se třeba používá dynamický wear leveling. Už z principu, pokud měním sektor, musím ho přesunout do čerstvě smazaného bloku a původní místo označit na smazání. Postupně se tak zaplní všechny prázdné bloky, a když začnou docházet, začne se řadič ohlížet o vhodném kandidátovi na smazání. Ideálně pokud najde takový blok, kde jsou všechny sektory označené na smazání. Pak nemá žádnou práci, prostě blok smaže a zařadí do seznamu prázdných. Pokud nenajde takový, pak jsou různé strategie, právě u dynamického wear levelingu se upřednostňují bloky, kde je málo obsazených sektorů, aby se nemuselo tolik dat relokovat, což podle mě zdržuje. Proto má overprovisioning (vyhrazení nepoužívané parition) smysl i flashek, hlavne proto, že neznám mnoho flashek, které by podporovaly TRIM (a mám pocit, že kernel linuxu TRIM na flasky ani neimplementuje).

Nevýhodou dynamického wearlevelingu je, že se omezuje jen na sektory, které se mění, zatímco statický wearleveling u SSD rozloží zátěž po celém disku, dynamický to rozkládá mezi měněné sektory a zbytkem volného místa. Další důvod pro overprovisioning na flashce.

164

Server / Re:Lomítka v adresářové cestě

« kdy: 20. 04. 2015, 21:11:45 »

Jestli ti to udělá radost, tak ve většina programů, které jsem psal, lomítko na konci cesty značí, že cesta vede na adresář (složku), zatímco pokud tam lomítko chybí, jedná se o jméno souboru. Má to vliv na odvozování například relativní cesty. Ale jestli to je stejný případ tady?

165

Software / Re:Bezpečný filesystem pre flash

« kdy: 20. 04. 2015, 15:00:14 »

Filesystem může být v zásadě jakýkoliv. Cokoliv co  tahá data po disku jak kočky koťata je ideální. Doporučuju ale koupit 2x větší flashku než plánovanou kapacitu a rozdělit jí na polovinu partition a polovinu nechat ležet ladem. Řadič ti poděkuje za extra místo pro volné bloky a taky tím zvýšíš životnost.