orcadk

Not really a fair comparison. If we're comparing to USB keys, you should at least compare to ephemeral SSDs rather than EBS SSDs. Unlike EBS, your USB disk isn't made for 99.999% durability, doesn't allow snapshotting, etc.

I think he's referring to the source code, rather than the game itself.

Cash use is about on par with most other countries. Credit cards & mobile solutions are slowly rising, but cash is still widely spread and necessary in some cases (like paying for public transport in certain cities, etc.).

The fatality rate would be the same. We do not have any treatments available for any of the Ebola strains, as such our only option is to limit the spread. Whether developed nations are better able to do so, I'm not sure.

If permissions could be granted not ahead of time, but rather when they're needed, you could simply update the application and just ask for permission when the new functioanlity was actually used.

You can't just compare storage on the capacity, you also have to account for speed. Even these days, 149GB 15k RPM SAS drives are popular for non-SSD usage. Long way from 4TB, but they outperform them any day when it comes to semi-random usage.

One could only hope. However, I don't see this changing the S3/CloudFront decision that much. I'm not sure if we're special, but on our bill, requests cover about 10% of the CloudFront total, compared to the transfer price, while requests cover just 2% of the S3 total price.

Except that's not the message.

The message is: Nobody is allowed to report misconduct in this way.

It's not just audio files; we've been seeing the same pattern (though actually even worse, as they request not only overlapping ranges, but the complete file, multiple times) on iOS5 for MP4 files: http://stackoverflow.com/questions/6094556/mobile-safari-mak...

I may get the patent on the smart cover, but I don't get how they could've been granted a patent on the flip page animation. The patent application is overly simplistic and clearly covers just the idea/design of the animation, rather than an actual implementation: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sec...

Furthermore, the web has been flooded with the exact same animation since the midst of 2004, all implemented in Flash. In the later years, these have also been implemented in pure HTML: https://github.com/blasten/turn.js

Given that Apples patent wasn't filed for until December 2011, I can't see why it wouldn't be dismissed on the grounds of prior art being publicly available.

> Instead of downloading the full 12Gb+ game, simply load levels/textures as needed

Blizzard has already executed this impressively for several of their titles. Starcraft II is an 8GB download, but after about 400MB you can actually start the game. It'll then continue downloading non-invasively in the background while loading needed data on demand. Same goes for World of Warcraft, and probably other titles as well.

Most of those issues stem from people recording with 30FPS. Having ridden thousands of miles with my GoPro's (1 & 2) mounted on my motorbike, I've come to realize that the quality is way better at 720p@60FPS compared to 1080p@30FPS. 120FPS @ WVGA removes the rolling shutter issue almost completely, but at that point the resolution is too low. I'm definitely looking forward to trying out 1080p@60FPS on the 3.

I don't agree that most secondary indexes are high cardinality. Some definitely are, but there are plenty of indexes with low cardinality, simply used for quicker scanning of those relevant values.

First up, in his example we're talking about 10k rows with a size of 35 bytes. At 8050 bytes of available space per page, that gives a fan-out of 8050/35 = 230. 10k/230*8kb = 350kb. At 350kb of inserts (hobt data, he doesn't go into secondary indexes), memory is completely irrelevant - the only force going on here is latency on writing the log to disk.

If we had a huge data set (as in, did not fit in memory, at all) with high cardinality - sure, we'd have a lot of cold leaf level pages. With no further info on his case, I can only assume most of the hobt and secondary indexes will fit in memory. At worst we'll have to read a cold leaf level page into memory to perform the addition in-memory.

As is there's no mention of even a clustered index, causing all of this to be heap inserts which is arguably one of the fastest insert methods there are (barring certain very special cases).

He already is using prepared statements, that happens under the hood when you use parameterized queries. Problem is the lack of type definition (in the first revision), causing a new compilation for each length of the varchar column.

There are quite a lot of inaccuracies in this post, as well as hints that don't really mean much.

First up, the non-SQL-injection code doesn't specify the parameter types. As such, each length of monster_class will result in a different execution plan being compiled and cached by SQL Server. Granted, there's only 50 different kinds - but just specify the parameter types to avoid it.

Sure, you could setup a VLAN, but we're lightyears from having that affect our performance at this point.

Parser overhead is not an issue as long as parameter types are specified. The plan will be compiled and cached. The only advantage to stored procedures at this point is reduced network data as well as management.

Page faults - Sure, but for inserts the data will most likely be in memory already as we're writing new data. And if there's enough data, the relevant b-tree pages will most certainly be hot.

Varchars - Granted, avoid them unless you're storing string data. I have no idea where the "hundreds of bytes of of memory" comes from. SQL Server caches all data as pages, exact copies of what's stored on disk. Variable-length varchars have an overhead of exactly two bytes + 2/#varlengthCOlumns in total.

Disk IO - The transaction log is never merged with the main data file. SQL Server uses write ahead logging, writing to the log first while modifying the data pages in memory. Now and then a checkpoint is run, writing all the dirty pages to the main data file. A log is only "merged" with the data file if the server has crashed and recovery is being run automatically during startup.

"This increases the number of rows you can insert before SQL Server succumbs to memory pressure" - Since the article only deals with inserts, why are we talking about memory pressure? You'll get disk contention for sure, but memory won't realistically be an issue unless you're reading as well.

There's an alternative to keeping the potentially long running transaction open - avoiding both SqlBulkCopy and transferring datatables. The BCL has a CommandSet notion that utilitizes a TDS feature that allows batches to be streamed to SQL Server. Unfortunately you'll have to use reflection to get at it (https://github.com/ayende/rhino-etl/blob/master/Rhino.Etl.Co...), but the code has been stable for several releases and is very simple to interface. It basically allows you to create normal SqlCommands and just send a large batch of them at once, all being executed atomically with minimal locking.

Finally, with the micro optimizations being mentioned, I'm surprised he doesn't recommend to "SET NOCOUNT OFF".

Overall, some good points with some inaccuracies. I have a hard time with the closing statement "As you can see, you don’t need to abandon SQL Server to get massive performance improvements.". These are decent improvements, but this is such a simple scenario that I find it pretty optimistic to let this define whether to abandon SQL Server or not. The RDBMS problem is rarely with inserting enough data, but with reading data at the same time while avoiding locking.

I wouldn't go as far as saying he's explicitly known for making racist jokes. He is however known for (and markets himself as) being politically incorrect - which may very well include both racism and chauvinism.

We are not, completely unrelated. The surnames are spelled differently too - Christensen (show-off) vs. Kristensen (BlogEngine).

Just to give a short recap of who this Mads Christensen guy is, coming from a Dane:

His tag line is "Denmarks big show-off" and he basically markets himself as a provocative bragging show-off, always with the rolexes, sports cars, slick hair and better-than-thy appearance.

He's not perceived as a comedian but rather as an entertainer hired for various corporate events - some obviously less successful than others.

Unless this was booked by Dell US without doing any kind of checkup, they would've been aware what would be coming. He's knowing for his provocative presentations and I have a hard time seeing exactly how a Danish Dell branch would find it appropriate or interesting to book Mads Christensen. If they wanted stand-up comedy we've got lots of skilled comedians. Mads Christensen is not in that line of work.

To be fair I don't think Mads Christensen personally believes what he presents on stage. It's the persona he's built up. Not that that makes it better in this scenario, just so flak is directed where it's most appropriate - Dell, and especially whoever made the decision to book him.

While this is an awesome idea, I can't help but think about the humongous potential for abuse. Were the logs to be leaked, stolen or otherwise compromised, you now have a goldmine of potentially vulnerable systems. Even if the results weren't logged, you'd now have a list of systems where the sysadmin wasn't 100% sure.

"For your security we do NOT store your IP address/result combination"

So the IP/result combination is not stored, but technically the IP address and result could be stored without there being a relation between them?

The columnstore indexes are purely read-only; they will not be updated without requiring a rebuild.

However, you can create columnstore indexes on specific partitions, and thus, by partitioning your source data, you can continue to add new data in new partitions. As most DW/"big data" solutions use partitioning anyways, this is a usable solution, giving you the benefits of the readonly performance as well as the maintainability aspects, while still allowing you to feed in new data.

Columnstore indexes are not meant for OLTP type solutions, so there's no need for realtime regular data deletion; it simply doesn't happen on this kind of historical data. You might switch out a partition of your data, or you might switch in a partition of new data, but you won't change the actual data itself.

Comparing SQL Servers columnstore index implementation with other columnstore based databases doesn't make sense. I won't laud columnstore indexes as a revolutionary new feature, but the way it's implemented is new, AFAIK. Comparing it to "normal" columnstore based databases will make SQL Server look bad - but the thing is, it's not meant to compete with those. Use it where it makes sense.

Lots and lots of countries don't have that, and it's no problem. The smallest coin we have in Denmark is the 0.5 Kroner one, worth roughly 10 cents. If you have to pay 1.24 Kroner, you pay 1 and if you have to pay 0.75 Kroner, you pay 1. You win some and you loose some - evens out in the long run.

It's filmed using a GoPro in the 4:3 mode which results in a fish eye effect, exacerbating the curvature of the Earth.

As the others mention, read performance is bad while in a degraded state. However, seeing as they're running their log on the same drives, they have quite a lot of write ops as well.

RAID5 is notoriously bad for write performance, just as RAID6 is. This is a classic writeup on why you should avoid RAID5 at all costs for a scenario like this: http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt

Demographics are more varied than that though - they also vary by Country. Take Denmark, the birthplace of several of the major players in flip catalogs - online flip based catalogs are so common that every internet going user knows what they are, and how to interact with them.

With such a common use of them, we can start looking at how to optimize the catalog format itself, rather than stick with the scrolling vs. catalog format discussion.

As there are lots of comments lamenting the fact that anyone might actually use this, let me give my perspective. I currently work for, and have been since the start of this whole online 3D-pageflip catalog business started back in ~2006.

To start out - I hate the pageflip effect. In the beginning, clients would drop the jaw to the floor when they saw the effect. They'd go into a coma when they saw you could drag the corners. We didn't have to do any sales beyond that - the effect alone sold it and the catalogs spread like wildfire. Sorry.

As time progressed, the pageflip effect alone didn't really cut it, especially as competition appeared. Since then we, as others, have gone in different directions, usually in the form of offering different addon modules, integration, etc. As time went on, the effect got diluted as well - we no longer offer the user the ability to actually drag the corners - usability testing proved that to be bad and cumbersome to use, instead you only get the option to flip the page by click big "Next/Previous" bars next to the catalogs. The effect is only seen while the pages flip automatically after an arrow click.

So why use the format at all? As many others say, normal scrolling is much more web friendly. However, there are billions of catalogs out there today, and millions more produced each and every day. Companies have hundreds of thousands of product manuals lying around, and they'd like to show them in a lightweight format that doesn't require you to download the 200mb PDF.

There are many retail chains that still send physical catalogs to your physical mail boxes each and every day. These catalogs are usually produced by print agencies on a weekly basis, and to also produce the same content in a webfriendly manner, that'd require tonnes of extra work. Instead, they can utilize what they're already producing and just put it online in an interesting format to read, for the common user.

To sum up - the flip effect was overused, but has now found a decent niche where it can be used. Lots of material warrant the format, even though it's not the optimal one.

I think turn.js looks very interesting. I have a boatload of catalogs running on Flash today, and I'd love to change that.