829 karma · joined October 13, 2011
Assuming it wasn't harmed is also speculation and we should definitely be concerned about the deal and what it means for net neutrality.
Comcast will also likely work with Netflix to estimate traffic growth and make sure their infrastructure scales before they have problems.
Again, we don't know the details of the deal. Assuming net neutrality was not damaged is also speculation. We need more information to know what is going on.
Peering is a practice where two sides agree to maintain their side of the infrastructure and not charge for metered bandwidth.
1. Netflix is currently using Cogent
2. Comcast offered them a direct connection to their network via paid-peering.
3. Netflix agreed and will move over.
4. Nothing about net neutrality was mentioned in the article.
This deal is being referred to as paid-peering. Peering is a practice performed at ISPs where two ISPs hook up infrastructure and agree to maintain their sides without charging for bandwidth. Peering is a common practice among the industry, and content-providers are always looking for ways to peer with more ISPs because it drives down their overall cost of operations.
The article says nothing about net neutrality. We don't have enough information to say whether net neutrality was harmed in this deal. We can only speculate at this time. Hopefully we will hear more from Netflix on this.
[edit to fix list formatting]
Domain names are still useful, for a start they provide some level of authentication when mixed with cryptography. (If you visit https://news.ycombinator.com, you can be relatively sure there is no MITM with certain conditions present).
It would be interesting to see how this system can be adapted to work with our current Internet infrastructure.
It was badly worded on my part, I was in a hurry. :)
Except these performance gains most likely would of been seen on a 32 bit version of the chip.
It's interesting to see how much marketing is put around 32 vs 64 bit chips and the effect it has on how people market. The biggest benefit is the ability to access more than 4GB of memory. For reference, the iPhone 5S has 1GB of memory. Eliminating the need for PAE and other expensive workarounds is definitely a bug plus. i64 and cheap doubles are certainly a bonus too.
I suspect the primary reason for moving to 64 bit is not for performance gains now, but for future compatibility. Eventually, the iPhone 5S will be the oldest supported iPhone and running a 64 bit processor will reduce maintenance costs of needing to maintain a 32 and 64 bit line of software.
I think this would be a much more informative article if the author had interviewed a few experts to discuss the benefits of 64 bits over 32 bits rather than just say they go faster which at this point is debatable.
Here are a couple examples:
myVar match {
case Some(val) => doSomething(val)
case None => handleNone()
}myVar.getOrElse("else")
In both of these cases, we eliminated the possibility of a NPE through the use of a language feature. :)
(edited for formatting)
Sales data: http://vgsales.wikia.com/wiki/Best_selling_Square-Enix_games
Wolfram has a large following in the academic world and improvements to his product line can turn into real results.
This isn't to discredit the author's viewpoint. I strongly agree with many of the assertions he makes. Backwards compatibility is a major problem.
Back to backwards compatibility (wee, puns), I think a major part of it is not due to ABI changes. The JVM has very well defined entry and exit points to deal with this. The problem seems to stem more with the libraries. As long as the libraries keep changing at a fast rate, the scala cmomunity will never achieve backwards compatibility at the level this author wants to achieve. Until typesafe makes a strong commitment to put APIs through a sunsetting lifecycle with deprecation, it will continue to be a problem.
Fortunately, they have made a commitment to not make breaking changes in minor releases. E.g. 2.10.0 compiled applications should continue to work with all release 2.10.* runtimes.
Skype API appears to be the same things as Skype Desktop API which is the ops focus.
SkypeKit which allowed developers to create a headless skype client is no longer accepting new developer registrations. https://support.skype.com/en/faq/FA12322/what-is-skypekit
I can't see anything at all about hardware that supports skype. This is probably through some enterprise BD channel. Hopefully they aren't being abandoned too.
A cheaper approach would be to translate from native to non native language using google (or whatever other free tool you want), and performing the same translation step w/friend to assess your progress.
If I am missing something, please speak up so or modify your blog so that we can make use of your technique.
For now, the best you can hope for is a layered defense and rigorous dev and ops practices to help minimize the attack surface and reduce the overall damage a single successful attack can achieve.
https://en.wikipedia.org/wiki/Bright's_disease
Another good example of misleading information is the last sentence: "In 1994, Linus Pauling died of prostate cancer."
He left out the part where he was 93 at the time of his death (1901-1994). Both the incidence and mortality rate for those over 80 are very high.
http://www.medinfographics.com/cancer-statistics/prostate-ca...
p.s. I do agree with the author in that I do believe taking Vitamins is largely unnecessary if you are eating a healthy diet w/lots of vegetables, legumes and fruit. :)
A github issue was created to incorporate BTRFS: https://github.com/dotcloud/docker/issues/443
Dotcloud blog post on dockerlite: http://blog.docker.io/2013/05/btrfs-support-for-docker/
Source: I saw the author's presentation at the docker meetup held at dotcloud a couple months ago.
You can get a windows build of aspell at http://aspell.net/win32/
Instructions are on the wiki on how to wire it up.