Příspěvky

361

Hardware / Re:Nákup tabletu: kdy budou čipy odolné proti M+S?

« kdy: 07. 02. 2018, 20:20:06 »

Celkem souhlas s Ondrou, trošku to rozvedu: Hodí se najít si něco ke konkrétnímu CPU. Ukážu to na konkrétním příkladě s mým telefonem. Často ke svému telefonu najdu, že mám Snapdragon 625, což je SoC. Když ten název hodím do Googlu a ještě přidám slovo "Cortex", vypadne na mě užitečnější informace, že to je osmijádro s Cortex-A53: https://www.notebookcheck.net/Qualcomm-Snapdragon-625-SoC-Benchmarks-and-Specs.175991.0.html . Zadám tedy do Googlu "cortex a53 spectre meltdown" (bez uvozovek) a vidím, že procesor není zranitelný.

Bacha na big.LITTLE, ty kombinují různá CPU. Třeba Snapdragon 808 má podle https://www.notebookcheck.net/Qualcomm-Snapdragon-808-MSM8992-SoC.117420.0.html jak Cortex A57, tak Cortex A53, a přepíná podle potřeby výkonu. Zatímco A53 je OK, A57 je zranitelný na Spectre.

Tyto CPU jsou ale méně výkonné z podstaty (přinejmenším single-core nedoženou...). Pokud budete chtít novější CPU a k tomu softwarovou mitigaci těchto zranitelností, potřebujete Android security patch level alespoň January 5, 2018. Nutno dodat, že to je spíš best-effort řešení, které se může časem ukázat jako neúčinné a může být potřeba novější update. (A obecně se z hlediska bezpečnost hodí, když se výrobce stará o updaty...)

362

Software / Re:Jak zvýšit bezpečnost při přístupu do internet. bankovnictví ?

« kdy: 02. 11. 2017, 16:51:53 »

Separátní profil trochu pomůže, omezí do jisté míry možnosti některých útoků jako CSRF/HEIST/CRIME a reflected XSS.

Doporučuji chodit do IB přes záložku (nebo v případě separátního profilu přes homepage). To zabrání překlepům apod. a nebude nutné vždy psát „https://“.

Zákaz pluginů a separátní VM – má smysl, ale ne až tak v profilu pro IB, ale hlavně v profilech pro stránky, které náhodně potkáte. Ideálně všechny potenciálně nebezpečné aktivity uzavřít do separátního virtuálního stroje. Tím se dostáváme ke zmíněnému QubesOS.

Anonymní režim zde IMHO nemá moc smysl. Separátní uživatel je taková slabší alternativa virtuálního stroje (a silnější alternativa separátního profilu). Při útoku záleží i na X11/Wayland, ale AFAIK i ve Waylandu je dost možností útoku, jako fake password prompt.

363

Software / Re:Oprava normálně psaného textu napsaného v režimu T9

« kdy: 02. 11. 2017, 16:34:01 »

O tom, že by T9 opravovalo překlepy, jsem neslyšel. Jak to znám, jen se to snaží doplňovat slova, která by tam mohla sedět. Pokud T9 byla zapnutá a neměla být, mělo by být celkem jednoduché zjistit, co bylo stisknuto, tedy například u znaků „a“, „b“, „c“, „á“, „č“ byla stisknuta klávesa 2, u znaků „d“, „e“, „f“, „ď“, „é“, „ě“ trojka atd. S pomocí nástrojů jako tr nebo sed (nebo prostého find&replace v obyčejném textovém editoru) by mělo jít to převést. Snad jediný potenciální problém zde vidím v tom, že se mohlo stát, že mobil najednou neznal žádné vhodné slovo, a odmítl dál (až do konce slova) psát.

Druhá část pak je převod posloupnosti číslic na text. To většinou asi půjde automaticky, i když by v tomto množství textu neměl být problém ani ručně. Je to ale do jisté míry víceznačné, např. 3336666 může být „demo“, nebo třeba „fom“. V některých případech více těchto variant může dávat smysl, ale snad to půjde pořešit ručně.

364

Hardware / Re:Jakou klávesnici pro linux

« kdy: 09. 10. 2017, 09:19:46 »

Ještě fotka: https://photos.app.goo.gl/5S6eEJLhJPSjp77F3

Barvy jsem často bral podle toho, co bylo zrovna v tiskárně.

365

Hardware / Re:Jakou klávesnici pro linux

« kdy: 09. 10. 2017, 09:10:40 »

Mám ErgoDox s hnědými spínači s vytištěnými DCS-like  keycaps. Keylayout obsahuje i stisky myši (včetně rolování a posunu kurzoru), pro přesnější pohyb kurzoru mám mezi půlkama touchpad.

Proč ErgoDox – má pro ruce přirozenější tvar. Nemá posuny řad (jako na psacím stroji), ale má posuny sloupců (protože máme různě dlouhé prsty). Je rozumně úzká, nemusím například přehmatávat na numerický blok a zase zpátky.

Hnědé spínače (Cherry MX Brown a podobné) – mají hmatovou taktilní odezvu (spínač se najednou „propadne“) a jsou relativně tiché.

Keycaps – každý řádek má trochu jiný tvar (zejména výška a náklon). Dají se koupit (DCS), ale některé tvary jsem nenašel a nechtěl jsem je nahrazovat generičtějšími, tak jsem si je domodeloval podle svých představ. A pod palcem mám taky trochu upravené klávesy. Trochu vlastní mám i bumps na hmatovou orientaci.

Myš – nebaví mě nahmatávat myš kvůli každé blbosti na pár vteřin, a pak se zase vracet na klávesnici a hledat, kde jsem skončil. Proto ten touchpad a často jej ani nepoužiju, vystačí mi směrové klávesy. Naučil jsem se s nimi víc, než jsem čekal. Akorát je lepší je dát například na „JKL;“ než někam dolů, jinak z toho bolí ruce.

Programovatelný layout – má. Je možné dokonce psát makra v C, i když to jsem nevyužil.

Dá se uvažovat i o různých tvarovanějších klávesnicích jako Kinesis Advantage. Tady už nevím, co přesně mě odradilo, snad horní řada kláves ve starší verzi klávesnice.

366

Hardware / Re:Spotřeba Intel i7 4850HQ v idle a na MacBooku

« kdy: 21. 07. 2017, 22:26:52 »

Zajímavé otázky. K EDRAM: Nemám pocit, že by to mělo ovlivnit nějak spotřebu, a když už, tak by to mělo leda snížit režii. Nicméně je možné, že se spotřeba EDRAM bude započítávat i do spotřeby CPU, a tím ji jakoby nafoukne (i když z hlediska celkové spotřeby to naopak možná trochu prospěje).

367

Studium a uplatnění / Re:Chtěl bych být bezpečnostní expert. Jak začít?

« kdy: 21. 11. 2016, 17:03:46 »

Pracuju jako bezpečák. Pár postřehů:

* Gentoo/Arch/… – dá to zkušenosti s Linuxem, pro dráhu bezpečáka bych to však nepovažoval za nezbytné. Pokud se ale chceš specializovat na Linux, pak proč ne…
* Google – v IT zásadní skill důležitý nejen pro bezpečáky. Řekl bych, že to není až tak těžké, ale spousta lidí s tím má problém. (Je fakt, že Gentoo/Arch naučí Googlit. Ale na druhou stranu, to se dá naučit i u mnoha jiných věcí.)
* Práce bezpečáka chce rozhled v oblasti, kde se pohybuje. Těžko přemýšlet třeba o cross-site request forgery, pokud nebudu znát web a autentizaci pomocí cookies. Těžko budu přemýšlet o buffer overflow, pokud nebudu znát lowlevel programování. A tak dále.
* A nejde jen o znalosti, jde i o praktickou zkušenost. Nejen jazyk, ale třeba i framework, typický styl (i kolegů) apod. Jak chceš hádat, jaké někdo může udělat chyby, když jsi jeho práci nikdy nedělal? Těžko. Myslím, že dobrý bezpečák se často snažil prvně naučit něco jiného, kde získal zkušenosti a pak se z něj stal teprve bezpečák.
* Různé kurzy k bezpečnosti: Ano, pokud chápeš principy útoků. To je rozdíl mezi hackerem a script kiddie.
* Lowlevel nemusí být kriticky nutný (například u webové bezpečnosti nevyužiješ moc často buffer overflow), ale pro rozhled se hodí. Třeba pro side channel attacks. Doporučuji se naučit třeba C, to mi pomohlo pochopit spoustu věcí. I když jsem v tom reálně zas tolik nenaprogramoval.

368

Studium a uplatnění / Re:Chtít víc peněz po skončení zkušební doby?

« kdy: 21. 11. 2016, 08:05:32 »

Snad tu nikdo nezpochybňuje, že požadovat vyšší mzdu ke konci zkušebky je v souladu se zákonem/smlouvou. Je tu já a pár dalších poukazujeme na to, že za některých okolností se to může být vnímáno neseriózně. Stejně jako máte právo požadovat vyšší mzdu den před koncem zkušebky, zaměstnavatel má právo vás den před koncem zkušebky propustit, propustit vás na hodinu za nějakou „blbost“ (něco, co by u jiných toleroval) nebo vás zařadit na vršek seznamu lidí k propuštění při nejbližším snižování nákladů. (A dalo by se pokračovat…)

Když už jsme u těch přirovnání: Představte si, že se s dělníkem dohodnete na ceně skoro celé koupelny, s tím, že pár drobností dohodnete potom. Koupelna je už skoro hotová, ale za těch pár drobností si dělník nasadí vysokou cenu. Vy můžete cenu akceptovat nebo si najít jiného dělníka (ale rekonstrukce koupelny se protáhne). Jistě, má právo požadovat jakoukoli cenu. Ale: najali byste si jej příště?

Dá se namítat, že přirovnání není dokonalé. Není:

* Když dělník bude  třeba 5 % nad můj odhad, mohu si říkat, že jsem špatně odhadnul. Kdysi zaměstnanec bude chtít přidat třeba i jen 1 % (haha), chce objektivně víc než byla původní dohoda.
* U dělníka mám dvě separátní rozhodnutí (zbytek prací na koupelně a práce v budoucnu), u zaměstnance jen jedno, ale o to závaznější. Tím spíš bych se někomu takovému vyhnul.

369

Studium a uplatnění / Re:Chtít víc peněz po skončení zkušební doby?

« kdy: 20. 11. 2016, 22:58:42 »

Pokud nejde o práci „u lopaty“ a nejde o start projektu, pak IMHO vždy je potřeba se seznámit s prostředím (platí i pro zkušeného) a je celkem pochopitelné dát za tuto dobu menší odměnu. Člověk, který bude chodit každé tři měsíce jinam, bude asi malým přínosem, a podle toho i dostane zaplaceno. Já například dostal bonusy až po zkušební době.

Na konci zkušebky mohou obě strany říct „ne“ nebo „ano, ale…“, otázkou ovšem je, jak to ta druhá strana přijme. Když se vžiju do role zaměstnavatele, může to působit neseriózně, pokud to přijde na poslední chvíli. Na jednu stranu to může projít (firma už do vás investovala a nechce si hledat jiného zaměstnance), na druhou stranu bych si řekl: Pokud mi teď dává malou chvíli na rozmyšlení, co od něj mohu čekat v budoucnu? Pokud mám poslední příležitost se snadno zbavit tohoto potenciálně problematického zaměstnance, nejspíš bych to udělal. I třeba za cenu, že bych kvůli tomu měl najmout někoho o trošku dražšího, ale předvídatelnějšího.

Přijde mi serióznější s případným přehodnocením odměny přijít co nejdříve. Ideálně by k němu ani nedošlo (domluvíme se už na začátku), dá se celkem akceptovat třeba v půlce, ale třeba den před koncem zkušebky je docela pozdě.

Taky je otázka, pokud to projde na poslední chvíli před koncem zkušebky (zaměstnanec je tedy nejspíš těžko postradatelný), jestli by to neprošlo i v dřívější fázi, byť třeba vágně „když se osvěčíš, přidáme na konci zkušebky 5000 CZK“. Taková dohoda sice těžko bude právně vymahatelná, ale jde o to, že požadavek na zvýšení mzdy nebude nic neočekávaného a zaměstnavatel dostává čas si to promyslet.

370

Vývoj / Re:Scala vs. Java 8.

« kdy: 01. 09. 2015, 14:36:44 »

Uznávám, že dnes není těch důvodů pro Scalu tolik, jako v době, kdy jsem přecházel já (2010). Tehdy byla Java 6 a pokusy programovat v Javě funkcionálně byly trochu krkolomné. Dnes je tu Java 8 a je to o poznání méně krkolomné, byť zdaleka ne ideální.

Kdyby tehdy tu byla Java 8, nevím, jestli bych na Scalu přecházel. Ale z dnešního pohledu by mi to přišlo škoda, Scala má stále co nabídnout.

Actor model – to je mnohem obecnější záležitost, jednotlivé actory mohou být i na úplně jiném stroji. A jinak toto bylo ve Scale deprecated a doporučuje se používat actory z Akka.

Funkcionální programování – zkoušel jsem Javu 8 a nedá se to srovnávat.
* Třeba udělat z kolekce Stringů kolekci java.net.URL jde ve Scale snadno, v Javě musím řešit checked exceptions. Ne, že bych vyloženě neměl checked exceptions rád, ale dokud tu nebude pro ně dobrá podpora v lambda funkcích, budou komplikovat funkcionální programování.
* Myslím, že pro Scalu je – aspoň dnes – lepší funkcionální ekosystém.

Immutable typy – ano, dá se to dělat i v Javě a já to tak dělal. Místo case classes se dá použít Lombok, který sice neumí úplně všechno, co case classes (např. pattern matching by v Javě neměl smysl), ale to základní ano. Na druhou stranu je tu trošku problém s ekosystémem – například když buu v Javě chtít (de)serializovat JSON do objektů, tuto konstrukci mi snad žádná knihovna podporovat nebude. Ve Scale použiju upickle nebo Play-JSON. V Javě ani jeden z nich tak snadno nepoužiju, protože to chce makra. Stručně: V Javě s tímto přístupem spíše narazím.

Klíčové slovo val, kdy pak není možné měnit proměnnou - Java má final – ano. Varianta s final je ukecanější, ale v zásadě ano.

Akademická syntaxe – nevím, jestli je akademická, ale vyhovuje mi celkem. Je svým způsobem jednodušší: například v syntaxi není níc jako typecast či instanceof – místo nich máme metody asInstanceOf a isInstanceOf. Nemáme operátor pro sčítání, třída Int má metodu „+“. (Kompilátor to pak zkompiluje vhodným způsobem, takže se to přeloží na checkcast, iadd apod. a žádné volání metody v takovémto bytecode nebude.)

XML syntaxe – pokud si dobře vzpomínám, tak ta se má z core jazyka oddělit do samostatného modulu. Snad má být implementována pomocí maker a string interpolation.

Databáze – je tu například knihovna Slick, za kterou dnes stojí Typesafe.

K „neklidnému vývoji“ – nemám pocit, že by tato výtka byla dnes na místě. Před pěti rokama ano. Dnes, když vyjde mová minor (setinková) verze, ověřuje se, že je 100% kompatibilní. Když vyšla nějaká desetiknová verze, slibovali kompatibilitu zdrojáků, s výjimkou zavržených a experiemntálních fíčur. A Dotty? To je dnes samostatný jazyk. Co je dnes v Dotty, to se může – pokud se to osvědčí – dostat časem do Scaly. Ale tím pískovištěm dnes není Scala, ale právě Dotty. Není to naopak dobře?

Mám pocit, že ke klidnějšímu vývoji přispělo i založení Typesafe.

371

Software / Re:LaTeX: fontenc se všemi znaky

« kdy: 03. 05. 2015, 22:32:00 »

Díky moc.

Aha, takže toto je už asi věc fontu. Příkaz \setromanfont{DejaVu Serif} rozhodne o tom, jestli se znaky „≤“ a „≥“ zobrazí správně. Takže asi omezení od Computer Modern.

Bez něj se navíc snad všechny non-ASCII znaky (vč. např. „ě“) kopírují jako \uXXXX. I když taky záleží, co všechno naberu, možná to tedy bude spíš nějaká specialita Evince.

372

Software / Re:LaTeX: Ideální fontenc – přímá podpora českých znaků a různích speciálních znaků

« kdy: 03. 05. 2015, 21:09:44 »

Možná ano, v těchto variantách se moc nevyznám. Zatím používám pdflatex.

Zkusil jsem XeLaTex. Zatím jsem dosáhl trošku jiného kompromisu. Nastavil jsem \usepackage[czech]{babel} a \usepackage{fontspec}, ostatní volby jsem zakomentoval. Čeština je v pohodě. Některé méně speciální znaky jako „<“ a „>“ taky. Fungují i znaky jako \„ a \“ (tj. české uvozovky) nebo „…“ (tj. výpustka). Už ale nefunguje třeba „≤“ nebo „≥“, místo toho se zobrazí bílé místo. Dělám něco špatně, nebo prostě tyto znaky nemá většina lidí na klávesnici, takže to jen ještě skoro nikdo neřešil?

373

Software / Re:Proč neexistuje univerzální CyanogenMod ROM?

« kdy: 03. 05. 2015, 20:48:35 »

U Ubuntu bylo počítáno s tím, že si to uživatel na počítač, na kterém nic takového nebylo, nainstaluje. U Windows taky. Google nic takového asi neřešil, prostě to nechal na výrobci. A CM? Co by se tím ušetřilo, kdyby byl jeden balík CM pro všechny telefony? (Dejme tomu aspoň v rámci dané architektury, nebudu chtít kompatilibitu napříč ARMv6, ARMv7, ARMv8, x86, …)
* Speciality těch jednotlivých telefonů by se musely řešit tak jako tak.
* Společný základ to má už dnes.
* Akorát by z toho byl jeden velký balík pro všechny telefony.
* Na druhou stranu, ta velikost by byla problém hlavně při stahování. Pokud by to zjistilo již při instalaci, co potřebuje a co ne…
* Ale stejně instalace se bude u různých telefonů lišit… Někde jde z recovery flashnout kernel, jinde se to musí zvlášť. Někde se odemyká bootloader přes výrobce, někde kutilsky a někde to není potřeba. A někde se použije kernel od výrobce (bootloader se nepodařilo odemknout…) a nabastlí se na to neoficiální „něco jako CM“.

374

Software / Re:Bezpečný filesystem pre flash

« kdy: 03. 05. 2015, 20:30:44 »

Řešit filesystém je možná trošku zbytečné, pokud flashka odejde zničehonic. Resp. vhodný filesystém to může trošku oddálit, ale to je tak všechno. Spíš bych se na to připravil a zálohoval.

375

Software / LaTeX: fontenc se všemi znaky

« kdy: 03. 05. 2015, 20:14:36 »

Zjistil jsem, že neznám ideální fontenc pro LaTeX. Mám dva kandidáty:

\usepackage[IL2]{fontenc} — znaky s diakritikou jsou ve výsledném PDF přímo, takže se dá v něm vyhledávat a ty znaky se dají kopírovat, ale je problém s jinými znaky, jako třeba „<“ nebo „>“. Ty by měly jít napsat přes nějakou de facto escape sekvenci, ale není to ono. (Navíc nevím, jak se pak taková escape sekcence projeví do výsledného textu, ale asi je to menší problém než u diakritiky.)

\usepackage[T1]{fontenc} – znaky jako „<“ a „>“ jsou v pohodě, ale znaky s diakritikou jsou problém. Sice se zobrazí, ale při kopírování nebo vyhledávání tam jsou úplně jiné znaky.

Existuje nějaká varianta bez těchto kompromisů?