274 karma · joined May 1, 2007
I really wanted the CryptoStick, looks like they're temporarily about of stock pending the new 2.0 revision, but not holding my breath.
http://shop.kernelconcepts.de/product_info.php?products_id=4...
keys is open source (GPLv3) and includes a basic Android app that runs the server. The code should run on iOS as well, but the lack of background networking is an issue.
keys provides strong protection for credentials. For details please read SECURITY, but to summarize everything is encrypted with AES in GCM mode using a randomly generated key, which in turn is encrypted with with a key derived from a password via the scrypt KDF. Network communication occurs over mutually authenticated TLS 1.2 connections.
If you'd like to try the Android app without the hassle of building it yourself, please join https://groups.google.com/forum/#!forum/keys-app and I'll send you a Play store beta test link.
Enjoy!
I wrote an x86-64 asm impl as part of my lightweight Java crypto library (https://github.com/wg/crypto) would be easy to drop into any C program: https://github.com/wg/crypto/blob/master/src/main/asm/rdrand...
Intel released an open source library too, though in tests my asm impl was faster ;-) http://software.intel.com/en-us/tags/20757
I guess Evernote's been around for a while, but wasn't it way back in 2010 that the BIS allowed simple self service registration and annual self classification of almost all "mass market" use of crypto?
Fortunately Typesafe has released a nice plain Java, with no dependencies, config library supporting similar syntax: https://github.com/typesafehub/config
The startup ecosystem exists, in large part, because a huge number of hackers created and freely gave away things like GCC, *BSD, Linux, PostgreSQL, MySQL, Redis, Apache, Nginx, Ruby, Python, etc. Without free, open source, software large amounts of funding would be necessary just to acquire the tools needed to build software systems.
People admire Louis CK's position because it strikes a good balance between the need to make money and the desire to share.
I currently run FreeBSD clusters with pf and varnish for load balancing, so relayd is my choice for SSL.
"2. Don't ever use scala.collection.mutable. Replacing a scala.collection.mutable.HashMap with a java.util.HashMap in a wrapper produced an order-of-magnitude performance benefit for one of these loops. Again, this led to some heinous code as any of its methods which took a Builder or CanBuildFrom would immediately land us with a mutable.HashMap. (We ended up using explicit external iterators and a while-loop, too.)"
Overall Scala<->Java interop is pretty seamless, and aside from some annoying things (for loop becomes foreach with a closure, break & continue are done with exceptions, etc) it's quite easy to treat Scala as a more concise Java with very similar performance.
Rather than using a Scala collections wrapper for the java.util.HashMap he should have simply used the Java HashMap as-is. Yes you must do hashMap.get("key") instead of Scala's shortcut hashMap("key"), but so what? You're talking performance-critical code already, wouldn't you want to avoid the wrapper?
I've found Scala to be a fabulous language for writing > 90% of my app(s). The overhead of Scala's built-in collections, for loops, property accessors/mutators, closures, etc is simply unimportant outside of critical hotspots and provides so much in terms of brevity and expressiveness.
Yes, Scala's lack of looping constructs (break, continue, a real indexed for loop) means that you're better off writing performance-critical things like crypto or protocol parsing code in Java (or if it really matters, C called via JNI). But once you're concerned about performance at that level, every language requires you to carefully consider what your code is really generating, what your allocation patterns are, etc.
Scala is a much more expressive language compared to Java, and the Scala standard library is excellent. Completely dropping Scala for Java when you're building large, complex systems seems like chopping your foot off because your small toe hurts. Use Java or C for the % of code that needs it and Scala for the rest!
In my experience the best reason to work for a startup is the freedom it gives you. No "architecture board" telling you what technology you can and can't use. No reprimands when you stray from your assigned niche.
I'd definitely advise against taking an insufficient salary and thinking the equity you may receive in exchange will cover the loss. The odds of that aren't really any better than gambling. Fortunately there are plenty of early-stage startups willing to pay fair salaries and decent benefits!
That fancy type system goes a long way towards helping to verify, at compile time, that your program is correct. Plus, with dynamically-typed languages you often have to build your own halfassed adhoc type system to check function parameters, map objects to db tables, (de)serialize JSON data, etc. Much better to use a well-thought out one built into the language, that also finds errors before the code is running!
Here's a little real-world example of using Scala types to define the response from a Foursquare JSON API call:
case class Response[T](meta: Meta, response: T)
case class Meta(code: Int)
case class MayorshipsResponse(mayorships: Mayorships)
case class Mayorships(count: Int, items: List[Mayorship])
case class Mayorship(venue: Venue)
Isn't the verification and documentation value of that so much better than using the typical dynamic language's map-of-maps and hoping you didn't mistype a string key name somewhere?Implicits provide a really nice way to extend the functionality of existing types. Instead of monkey patching, which pollutes your entire program, you can simply write a wrapper class that provides new functionality and an implicit conversion. This is how Scala can give raw Java Arrays the same rich set of methods that any native Scala collection has, and how the standard "map" method can be defined generically but still build & return the expected result collection type.
Syntactic sugar is arguably a problem, there are definitely a lot of special cases to learn and remember: when can parenthesis be omitted, when can curly braces replace parenthesis, special methods with symbol names like "::", ":+", "@", etc. But in the long run I think the sugar does make code easier to read.
Compare a single "map" function in Erlang (a language that really eschews syntactic sugar):
lists:map(fun(N) -> N + 1 end, [1, 2, 3]).
vs Scala: List(1, 2, 3).map(_ + 1)
which is really just syntactic sugar for: List(1, 2, 3).map({(n: Int) => n + 1})
I think that in the long run I'd rather memorize some rules (as long as they're reasonable and logical) rather than have to read/write through a ton of boilerplate every time I declare a closure.They claim greater reliability for the new 320 series which is based on the same controller hardware, and have upped the warranty of that from 3 to 5 years: http://newsroom.intel.com/community/intel_newsroom/blog/2011...
There definitely has been a lot of noise about high failure rates in OCZ's Vertex series, but it doesn't seem to be anything inherent in SSDs or even the SandForce chipset. OCZ shipped SSDs with pre-release firmware, uses a number of different flash chip vendors, and may not test sufficiently prior to release.
I'd say buying a reliable SSD is more difficult than buying a HDD since there are quite a few variables, but there is sufficient information available these days to make an informed choice.
Performance is really worth it though! I wish there wasn't such a focus on boot times because I only have to reboot my MacBook Pro for certain OS updates or when it crashes, but high performance random IO makes a huge difference in day to day use. Applications launch almost instantly, I can do a find+grep on nested directories containing thousands of files in a fraction of a second, and compile times are pretty much only limited by CPU speed.
I'm not a potential hire but your visit sounds like a good excuse for an informal meetup of hacker news readers in Tokyo. Have time?
The mercurial CLI is well thought out and easy to use vs git's incredible number of commands and command line options, and is also similar to SVN which probably helps get people up to speed. Generally with hg there's one right way to do things, but many with git.
As far as shooting yourself in the foot goes, git's ability to rewrite history is great for maintaining a clean revision history even after commits are made. Rebasing is quite handy for keeping multiple branches up to date and easy to merge. But these are power tools that can result a lot of pain if they aren't used properly.
I switched to git because the extra power and flexibility was more than worth the cost, and git's branching model ends up working much better for me, but mercurial is a very nice tool!
I'd say go for the SSD. I just upgraded to a 240GB OCZ Vertex 2 and the speed boost is almost unbelievable.
All of these tools encourage running the JVM outside of emacs, rather than as an inferior-lisp, and have some command line option that starts a swank server on a specified port. After that you can just do M-x slime-connect and get hacking as usual =)