No. Most NATs handle UDP sessions trivially as long as one end of the connection is not behind a NAT itself. Tricks like UDP hole punching are necessary only between two endpoints that are both behind NATs.
1,606 karma · joined February 20, 2009
I don't know how this claim could be verified in our lifetimes.
Facebook uses Blu-ray discs with a robotic storage system for its cold storage: http://www.datacenterdynamics.com/it-networks/robot-digs-thr...
This doesn't solve your problem of the $250/room cost, but if you'd like to use some other thermostats in your rooms this would work great.
The only complaint I'd have about mine is that the relay is very loud. You might want to search for a quieter one.
Approximately $5.1B of Samsung's profits came from their phones; this is despite Samsung being an extremely diversified company. I cannot find what proportion of Apple's profits come from sales of iPhone and iPads; they do, however, make up a majority of their revenue.
The preferred method, for iOS apps at least, seems to be use reference counting. This implies that any objects with cyclical references will not be released. Thus, the semantics of this approach will be subtly different than that all JVMs, which have GCs which can detect cyclical references. Thus, the documentation suggests using "runtime and tool support to detect memory leaks".
It's a shame, but given the amount that Azul has poured into research it is not surprising.
At least we can look forward to some interesting benchmarks and code analyses, perhaps?
As far as crafting input to match allocated addresses, that is an interesting idea. One could, at the very least, create data that lies within the heap's address range. The issue is, you'd need a lot of data to blacklist a significant amount of memory, and if that's the case why not just DoS with a ton of data?
In practice, a fragmented heap is probably a much bigger issue than actual leaks. As the article points out, a conservative GC cannot perform compaction.
One major cause of the problem seems to be that Scala is stuck with the "precompiled bytecode in JARs" model of software distribution; while this may be appropriate for Java (where core developers go through great pains to maintain compatibility between versions) it seems like a poor fit for Scala. Not only do the core library APIs change between versions, but the conventions used by the compiler to "link" Scala code together are also altered, for good reason.
An alternative distribution mechanism that's more resistant to these kinds of issues might make sense. Even just distributing source code and build files (like, say, Ruby) could be a better solution. Building dependencies might be slow at first, but centralized caching could address this. Another solution might be an intermediate representation (after type-checking and other compiler phases, but before "linking") that gives the Scala compiler the knowledge that's missing from compiled class files.
Even namespace-mangling or class-loader magic could be helpful here. Loading multiple versions of a single dependency should in theory be possible, since OSGi manages it.
Sadly, there seems to be a pretty large investment by the Scala community in the whole Java/Maven/JAR ecosystem. It'd take a concerted effort by many people to create a more robust solution.
However, like all the Twitter Scala libraries, it's currently stuck at 2.8.1 (2.9.0, the next version, was released May 2001). Most new Scala libraries are only being released for 2.9.x, meaning that most developers are forced to make a choice between using Twitter's libraries or other, newer ones.
Further, there are several outstanding pull requests on GitHub to add 2.9.1 support. It was relatively trivial to update the libraries to 2.9.1, but they're not getting integrated. I haven't gotten any feedback about when these might get merged, or why Twitter is stuck on 2.8.1. I've heard through third parties that this is due to problems with Java interoperability with 2.9.1. Also, the custom SBT plugins used seem to, for some reason, break SBT's ability to cross-build.
Unlike with Ruby gems, using forked dependencies is non-trivial.
I intend to keep using Scala. This problem, however, is representative of the relative lack of maturity of the Scala ecosystem. I hope and anticipate this will be resolved in the future. As of now, they represent real problems that get in the way of delivering working code.
Obviously Intel (once led by Andy Grove, author of "Only the Paranoid Survive") is aware of the threat posed by ARM. If someone could explain how Intel will fail to meet the challenges of getting x86's performance-per-watt to match ARM's, and how this compares to the challenges ARM vendors face in order to get raw performance up to Intel's level, I would love to read it. However, this post offers little such insight.
"Note that if W + R > ReplicationFactor, where W is the number of nodes to block for on write, and R the number to block for on reads, you will have strongly consistent behavior; that is, readers will always see the most recent write."
Could you explain why this is incorrect? It seems the Cassandra devs use the definition of "consistency" from Brewer's paper, and Cassandra offers this level of consistency.
Your point about read-repair is correct when using QUORUM consistency level, but even then you can avoid that by using the ALL consistency level.
There is a general misconception that the an entire DBMS must pick tradeoffs based on the CAP theorem. (IE, you can use a database that offers availability, but can NEVER offer immediate consistency) Instead, a DBMS may offer different CAP guarantees per operation.
The likely situation is that the US will pay down its debt through a combination of spending cuts and tax hikes. But there is no doubt that the tax hikes will be substantial.
I believe we're in a pretty poisonous political environment, where the dominant strategy for a politician seems to be to convince your constituents that they're being taken advantage of. Most people who benefit from government programs don't realize it (see http://economix.blogs.nytimes.com/2011/02/11/keep-your-gover...), and most voters have an incredibly skewed view of what, exactly, the government spends money on. When polled, voters oppose cuts to almost every major program.
That the median voter has largely incoherent views on the budget, but is very angry about it, leads us right into our current mess.
To my original point: OP's argument is big on righteous indignation, along with a narrative that allows him to cast himself as a "good guy" and short on actual facts to how to dig our way out of this mess.
* He largely ignores the potential for a catastrophic financial collapse in 2008-2009. At the time, pretty much everyone agreed that stopping the bleeding was a good idea. Among economists, that some sort of vigorous action was necessary is close to a consensus view. To completely dismiss this is ridiculous. Further, he doesn't address how expensive TARP actually ended up being, or that the majority of the money has been paid back.
* The funds weren't obtained from "new taxes levied on employed, middle class, non-drinkers who have never set foot in Heidi’s bar." There has been no increase in federal income taxes since Obama took office. The only meaningful tax increases that I can recall come as part of the Affordable Care Act.
* The author makes no concrete arguments for why no changes to financial regulations are unnecessary. Instead, there's a glib aside that the 'government also announces a series of regulations to “fix” the problem'. Really? This is important. Tell us why. If the government had stopped banks from selling Heidi's bonds as AAA-rated securities, wouldn't this crisis have not happened?
Overall, this is a simple, facile metaphor with many implicit assumptions, designed to bolster the author's libertarian worldview. To the author's credit, he does a good job explaining the fundamentals of the housing crisis.
However, Oracle is working on a JavaScript implementation that leverages it: http://www.wiki.jvmlangsummit.com/images/c/ce/Nashorn.pdf. See also https://github.com/dynjs/dyn.js, another incipient JavaScript implementation.
The most frequently cited reason is to take advantage of JRuby's generally quite excellent Java interoperability. In many cases it may be the best way to introduce Ruby into an organization with a large, legacy Java codebase. Further, despite its oft-maligned reputation, Java still offers the largest number of high-quality, performant FOSS libraries of any platform. In our case, we are developing a Rails application along with a supporting Scala library simultaneously. In my experience, JRuby/Java/Scala integration is largely painless.
Further, JRuby could legitimately be considered the best Ruby implementation. It's very rare to find pure Ruby code that works on any other Ruby implementation but not JRuby. JRuby is, in general, faster than Ruby 1.9 (and in almost all cases much faster than 1.8). Further, upcoming enhancements in JDK 7 may allow some very impressive speed-ups (see http://blog.headius.com/2011/08/jruby-and-java-7-what-to-exp...).
On the other hand, it's arrogant for one to think that he or she could do it that much better than the next guy. Writing efficient, maintainable, and "simple" software requires adding layers of indirection and complexity. You have to use your best judgment to ask whether the new layer you're adding will make things ultimately cleaner and simpler for future generations of programmers, or will hang like a millstone around their necks for years to come.
Let's try a little thought experiment: go back a few decades to the early 80s. Propose to build node.js as a tool to make it much easier for developers to write real-time network applications. You'll need to design a prototype-based dynamic language, itself an extremely difficult (and dare I say complicated) task. The implementation will need a garbage-collector, a delicate, complicated, and cumbersome piece of code to write. To make it acceptably fast, you'll need to write a JIT, which traces and profiles running code, then hot-swaps out JITted routines without missing a beat. You'll need to write a library which abstracts away event-based IO, like the "libev" node.js uses. That will require kernel support.
Frankly, even forgetting about relative CPU power at the time, I think you'd be laughed out of the room for proposing this. All of these things, for production systems, were extremely speculative, "complicated" things at the time they were introduced. People can't predict the future, and they obviously have difficulty predicting what tools will become useful and simple, and which will become crufty tarpits of painful dependencies and incidental complexity. No one in 1988 could say "a dynamic, prototype-based, garbage-collected language paired with a simple event model will allow developers to create simple real-time network applications easily in 2011". Many of them probably had high hopes that C++ templates would deliver on the same vision by then. But, instead, we have Boost.
Further, it's extremely arrogant of Dahl to create a dichotomy between those who "just don't yet understand how utterly fucked the whole thing is" and those, like him, with the self-proclaimed power of clear vision to see what will help us tame and conquer this complexity. Who knows, maybe in 15 years we'll be saddled with tons of crufty, callback-soup, unreliable node.js applications we'll all have to maintain. I don't think James Gosling envisioned the mess that "enterprise Java" became when he designed the initial simple language. Most developers do many of the things he cites, like adding "unnecessary" hierarchies to their project, because they believe it will help them in conquering complexity, and leave something simple and powerful for others to use down the line.
In the longer term, however, I fail to see how Netflix can avoid having its product turn into a commodity. Delivery of digital video to consumers will only continue to get cheaper and easier. Obviously Netflix has gotten amazing deals on bandwidth (see their recent spat with Comcast) but other the prices it pays will only continue to converge with the prices for commodity CDNs.
The only major part of Netflix's business that's resistant to commoditization is having a huge base of subscribers that allows them to cut deals directly with studios like Dreamworks. Obviously Netflix is trying to position itself as a cheaper, better middleman between consumers and content producers than the combination of cable channels and cable companies. This could be very attractive to studios in the medium-term, but ultimately why not cut out the middleman? When (not if) quick, flexible, and easy online payment comes to the internet, what's stopping Dreamworks from simply charging and delivering the movie to consumers directly?
I purchased a (relatively) inexpensive hand-cranked base from http://www.kitchensource.com/table-bases/gb-1000-1001.htm. I also got a cheap ($30) 48" x 24" x 2" wooden tabletop which I was able to sand, finish, and easily mount to the base. I added a desk-mounted monitor arm (http://www.amazon.com/gp/product/B001IWOBGI). The price for all of this compares extremely favorably to most other adjustable desks I've found.
This setup has been a huge help for my back issues. If I were to try to quantify the cost of having a sore back that renders me unable to be active, it'd be vastly higher than what I payed for this setup. If I am offered a position where I need to go into an office, I would make offering me a similar setup a precondition of me accepting the offer.
Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, parser, and parts that compile the AST to bytecode is all written in pure Ruby. Further, large parts of the standard library and Ruby language that are implemented in lower-level languages in other implementations are instead written as runtime-level Ruby. However, large and important parts of the infrastructure (including GC and memory allocation) are written in C++.
PyPy takes an altogether different approach. It specifies a restricted subset of Python known as "RPython". Basically, it's statically-typed Python. There is also a "compiler" (also called a "JIT generator"), written in pure Python, that compiles an arbitrary interpreter written in RPython into a fast JIT. (See http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... for an example of writing a very simple, small interpreter in RPython.) A cool feature of RPython is that while there must a statically RPython AST to compile, during the "eval" stage you can leverage the full dynamic capabilities of Python.
The second part of PyPy is a full Python interpreter written in RPython. Since RPython is a subset of Python, you can actually run this interpreter sandboxed inside any other Python implementation, albeit very slowly. The PyPy toolchain compiles this down to a very fast Python interpreter that features JIT compilation, among other cool features.
The neat part of PyPy (in contrast to Rubinius) is that the toolchain part is largely decoupled and generalized away from Python-the-language. Conceivably, one could write ANY language in RPython (or what's compiled down to RPython) and have a fast JIT interpreter. Experimental language features can be added and changed (see the source code for the different garbage collectors in PyPy) with little mucking with the low-level VM.
Rubinius is a neat, pragmatic project that could turn into one of the best Ruby implementations around. However, it's not breaking new ground like PyPy is.
Besides CoffeeScript, which mostly only offers syntactic improvements to JavaScript, there are several projects which compile very different languages to JS, including:
* Emscripten (http://emscripten.org/) compiles arbitrary LLVM bitcode to JavaScript. Since clang and GCC can both target LLVM, a whole lot can be compiled to JavaScript. The Python interpreter (http://syntensity.com/static/python.html) and the Bullet physics engine (http://www.syntensity.com/static/bullet.html) are both particularly impressive.
* Google Web Toolkit (http://code.google.com/webtoolkit/) compiles Java to JavaScript. It's used in many real projects. Scala+GWT (http://scalagwt.gogoego.com/) aims to use this toolchain to compile Scala code, though it's not yet production-ready.
* The reductio ad absurdum of this approach is http://bellard.org/jslinux/, a x86 PC emulator written in JavaScript. You can run almost any language in the web browser with that!
See https://github.com/jashkenas/coffee-script/wiki/List-of-lang... for a (possibly exhaustive) list of languages like this.
Whether these approaches can deliver passable performance for legacy browsers is an open question. However, for newer browsers it's safe to assume this general approach holds a lot of promise.
"We are four faster than Hadoop on the Thor side. If Hadoop needs 1,000 nodes we can do it with 250 – that means less cooling and data center space."
We should reserve judgement until these things are actually open-sourced.