1
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.
2
Software / Re:inplace sifrovani disku
« kdy: 23. 03. 2015, 16:26:25 »
cryptsetup to umí, jen nesmíte použít luks. A musíte si pamatovat šifru, hash, atp. sám.
3
Server / Re:startssl a bezpecnost
« kdy: 18. 03. 2015, 00:08:09 »
Je to trochu paranoidní představa, ale v principu jim v tom nic moc nebrání a nelze doporučit generovat si soukromý klíč přes jejich rozhraní. Nemusíte (neměl byste) to ale dělat - stačí tu stránku přeskočit a dostanete možnost vložit pouze "žádost", kterou si vygenerujete u sebe pomocí např. openssl.
4
Vývoj / Re:výjimka vs assert
« kdy: 25. 01. 2015, 13:26:47 »
Výjimky jsou v C++ dobré v situaci, kdy máte dobře navrženou aplikaci, rozdělené akce atp. Dokážete tak zajistit smysluplnou recovery i z věcí, o kterých ani netušíte, že mohou nastat. Nicméně mají i řadu nevýhod, z toho největší jest asi ztráta kontextu, co se vlastně rozbilo (aby se to mohlo opravit) a boj s realitou, že v C++ existují pravděpodobně až miliardy řádek různých knihoven, které použití výjimek moc nenapomáhají a člověk dojde k názoru, že mu výjimky jen komplikují vlastní řešení (které je co do rozsahu významně menší než API, které používá).
Assert zase funguje jen v debug konfiguraci a jak mnozí uvádějí, jde o kontrakt, že daná situace nemá (nesmí) nastat. Osobně jej rozšiřuji i na situace druhu invalid_argument, ale souhlasím s tím, že takový argument nesmí pocházet od uživatele. Assert, na rozdíl od výjimky, jasně sděluje, že situace nastat nesmí a je třeba ji řešit, a navíc poskytuje vývojáři kompletní dump včetně stacku a lokálních proměnných, takže je nesrovnatelně snazší opravit assert než výjimku std::out_of_range.
Zjednodušeně, asserty dávám tam, kam nechci, aby se kód nikdy dostal, výjimky tam, kde doufám v recovery. A často kombinuji obojí, tedy dám assert před výjimku. Ale diskuse, kdy házet výjimku a kdy vrátit chybu pomocí return value, to je asi na delší povídání.
Assert zase funguje jen v debug konfiguraci a jak mnozí uvádějí, jde o kontrakt, že daná situace nemá (nesmí) nastat. Osobně jej rozšiřuji i na situace druhu invalid_argument, ale souhlasím s tím, že takový argument nesmí pocházet od uživatele. Assert, na rozdíl od výjimky, jasně sděluje, že situace nastat nesmí a je třeba ji řešit, a navíc poskytuje vývojáři kompletní dump včetně stacku a lokálních proměnných, takže je nesrovnatelně snazší opravit assert než výjimku std::out_of_range.
Zjednodušeně, asserty dávám tam, kam nechci, aby se kód nikdy dostal, výjimky tam, kde doufám v recovery. A často kombinuji obojí, tedy dám assert před výjimku. Ale diskuse, kdy házet výjimku a kdy vrátit chybu pomocí return value, to je asi na delší povídání.
5
Sítě / Re:IPv6 tunel od HE problémy
« kdy: 07. 10. 2014, 19:56:54 »
Taktéž používám HE (skrz UPC) a obě zmiňované stránky otevřu bez potíží.
6
Hardware / Re:Dvě myši na jeden přijímač
« kdy: 05. 07. 2014, 02:46:36 »
Logitechy to umí snad všechny. Stačí najít model s "Unifying Receiver", což dnes bude spíše problém nenajít (a navíc i staré myši, které to neměly, fungují s tímto novým receiverem) a můžete vesele myšovat.
Viz http://en.wikipedia.org/wiki/Logitech_Unifying_receiver
Viz http://en.wikipedia.org/wiki/Logitech_Unifying_receiver
7
Windows a jiné systémy / Re:Start aplikace bez přihlášení
« kdy: 30. 06. 2014, 20:30:11 »
Použít TeamViewer nebo *VNC není možnost? Ti pracují přímo v konzoli.
8
Windows a jiné systémy / Re:Start aplikace bez přihlášení
« kdy: 30. 06. 2014, 16:47:39 »
S interaktivními službami už dnes nepochodíte. Tento požadavek se prakticky výhradně řeší standardní službou se separátním GUI (startovaném "Po spuštění") a tyto dvě aplikace si spolu nějak (zabezpečeně) povídají (RPC, eventy, ...).
Nicméně @a903user to popsal také dobře: heslo uživateli zůstane, ale přihlásí se automaticky a RDP by mělo fungovat normálně. Nicméně mi to přijde jako dosti křehká varianta, která se rozsype při prvním problému.
Čeho se vůbec snažíš dosáhnout?
Nicméně @a903user to popsal také dobře: heslo uživateli zůstane, ale přihlásí se automaticky a RDP by mělo fungovat normálně. Nicméně mi to přijde jako dosti křehká varianta, která se rozsype při prvním problému.
Čeho se vůbec snažíš dosáhnout?
10
Hardware / Re:Indexovanie súborov na SSD disku
« kdy: 11. 06. 2014, 13:14:55 »Proč by mělo? Oddíl je věc OS, TRIM se posílá na LBA a tato adresace je v režii SSD, tj. SSD si může bloky volně přelévat mezi oddíly.Jen poznamenám, že důležité je volné místo v součtu, rozložení přes oddíly není podstatné.Rozložení přes oddlíly samozřejmě podstatné je.
Tazatel: Ano, disk má o něco vyšší kapacitu než jaká je na něm uvedena, ale pakliže chcete klást na výdrž ještě větší důraz, můžete se dobrovolně vzdát další kapacity ve prospěch trvanlivosti. Stejně dobře ale funguje i volné místo (se zapnutým TRIM).
11
Hardware / Re:Indexovanie súborov na SSD disku
« kdy: 10. 06. 2014, 01:19:23 »
Jakub: Neřeknu, jak je to u tvého disku, ale Samsung údajně uvádí podobnou hodnotu (177: Wear Leveling Count) jako maximální počet přepisů jednoho bloku; u mě je to 44 raw.
Spíše jsem chtěl otevřít debatu, jak velký smysl má omezovat se u počtu zápisů za situace, kdy Samsung 840 Pro vydrží dle testů cca 1 PB zápisů, což by u mě činilo nějakých 100 let a to si myslím, že SSD trápím jako málokdo. Samsung 840 Evo má myslím TLC, takže na tom bude o něco hůře (2×, 3× (?)), ale opravdu bych se tím nijak zvlášť netrápil.
Spíše jsem chtěl otevřít debatu, jak velký smysl má omezovat se u počtu zápisů za situace, kdy Samsung 840 Pro vydrží dle testů cca 1 PB zápisů, což by u mě činilo nějakých 100 let a to si myslím, že SSD trápím jako málokdo. Samsung 840 Evo má myslím TLC, takže na tom bude o něco hůře (2×, 3× (?)), ale opravdu bych se tím nijak zvlášť netrápil.
12
Hardware / Re:Indexovanie súborov na SSD disku
« kdy: 09. 06. 2014, 23:32:18 »
Přesně tak, Samsung Magician v tomto případě. 3839 hod. a 10161568529 sektorů * 512 B ~= 4.73 TiB.
13
Hardware / Re:Indexovanie súborov na SSD disku
« kdy: 09. 06. 2014, 20:25:09 »
SSD nevadí čtení, tudíž procházení disku není podstatné, opotřebovává se zápisy. Nicméně, v práci jsme měli nějaká SSD, která odcházela do několika měsíců, ale zrovna Samsungy jsou celkem držáky (byť můžu referovat jen o "Pro" edici), že bych to kvůli nějaké indexaci neřešil.
Mám 256 GB SSD cca půl roku, zapsáno 4.7 TB (~30 GB/d) a zatím si nestěžuje. Pochybuji, že indexací zapíšeš víc než pár stovek MB denně.
Mám 256 GB SSD cca půl roku, zapsáno 4.7 TB (~30 GB/d) a zatím si nestěžuje. Pochybuji, že indexací zapíšeš víc než pár stovek MB denně.
14
Vývoj / Re:Šifrovací knihovnu s obtížným dešifrováním
« kdy: 01. 02. 2014, 13:12:21 »
Obecně se to řeší tak, že zprávu zašifrujete mnohokrát dokola (desítky i stovky tisíc průchodů).
15
Server / Re:Co když ztratím SSH klíč?
« kdy: 29. 01. 2014, 14:26:50 »
Především platí, že jednou root, navždy root. Toto celé má tak smysl provádět jen pokud máte jistotu, že ještě nedošlo ke zneužití toho klíče.
A jediný způsob, jak toho alespoň proti některým typům útoku docílit, je remote logging na zabetonovaný server, který akceptuje pouze příkazy "INSERT INTO".
A jediný způsob, jak toho alespoň proti některým typům útoku docílit, je remote logging na zabetonovaný server, který akceptuje pouze příkazy "INSERT INTO".