jaylevitt

Maybe that's theoretically true - but so far, copyright wars aside, it's been moving in the other direction, as storage and bandwidth get ever cheaper. One person finds a Super-8 film when they renovate the attic, it gets transferred, they upload it to YouTube, and now it's permanently on the Internet.

You can now listen to the earliest recorded audio[1] (which was never heard or playable in its own time), read many of Isaac Newton's original manuscripts[2] (with plans to triple the archive this year), and google ["yeeees" guy] to watch a clip of Frank Nelson[3].

You don't have to excavate at all; you just have to make it searchable so that someday, someone will run across it. This is what we have with just text search. Now add in PhotoSynth (the original, Flickr-driven version[4] with every photo ever, not the watered-down panorama app), automatic audio transcription, content-aware image search, "hum that tune" (Shazam, SoundHound, etc.). Within a decade, we'll have "imagine that video and search for it".

"Movage" becomes less of a problem because while it's not worth it for you to individually convert various old files on your hard drive, Google has no problem re-encoding their entire library to add HTML5 codecs: Write the script once and wait a few years for it to finish. It's already in some master, readable format, so they don't have the "ten versions of Word .DOCs" problem (or if they do, they hide it very well).

If anything, we're entering an age where nothing goes out of print, and there are no lost films. Ever. Yes, we have to fight some copyright battles, but the outcome is inevitable; in 50 years, all laws will be written by people who grew up with BitTorrent, not the DuMont network.

Someone coined a great term for this new age of digital plenty, but I forgot it. In ten years, I'll be able to Google that thought and tell you what it was.

[1] http://gizmodo.com/372994/earliest-audio-recording-resurrect...

[2] http://www.newtonproject.sussex.ac.uk/prism.php?id=1

[3] http://www.youtube.com/watch?v=JA_r1Ynl4Ls

[4] http://www.youtube.com/watch?v=s-DqZ8jAmv0

I think by "RESTful thinking" he means "cargo-culting the Rails RESTful scaffolding".

In fact, if you're using Amazon's CloudFront CDN, and you're using HTTPS, you have NO way to keep everything under the same TLD; CloudFront can only serve its own SSL cert, not yours.

I don't think a "button" quite conveys the malicious feeling you want to inspire... but maybe a "Read more" link?

Because rationality is a myth; we are mammals with language skills. Evolution has taught us that only things in the here and now can hurt us, and decisions we made (or really, failed to make by accepting defaults) last year are harmless.

Apple's being unintentionally ironic here. Their second attempt at an online service was eWorld, which was based around a modified AOL client talking to a modified AOL server. They took our client software, which looked like this:

http://1.bp.blogspot.com/-CukACmTPP8Q/TxxdPO_B8HI/AAAAAAAADd...

and, using our existing UI tools, made it look like this:

http://www.ilenesmachine.com/eworld/images_eworld/eworldone....

We had no idea that was possible.

Lesson: You do want your users customizing the interface.. but only the right users.

Am I the only one disappointed by this move? They moved to a registrar so split between their role as registrar and their stance as anti-piracy that they couldn't even take a stand on SOPA?

http://startupdispatch.com/analysis/analysis-9-of-top-500-we...

We're actually working on this from a slightly different angle; rather than "revealed preferences" and machine learning, we're using surveys of psychologically-validated, taste-predicting traits.

IANAL, but as I recall you are practically required to have such a licensing clause, lest someone:

1. Pin their own copyrighted work 2. Wait for someone else to view it on Pinterest 3. Sue Pinterest for distributing or performing it.

You don't actually need to make the filter friendlier to advertising. Rankings change every time they re-run the algorithm. You hint that things will be better if I advertise; 50% of the time, that's true.

http://www.skepdic.com/perfectprediction.html

Typical global-warming propaganda.. :)

As someone who found four compiler bugs in three weeks - in a five-nines fault-tolerant OS, yet! - and who found a PostgreSQL optimizer bug within weeks of learning SQL, I think the key to being "that guy" is playing five-whys with every single bug you encounter.

I work with some very talented developers who, when they try something and it doesn't work, try something else. I am fundamentally incapable of that. If it doesn't work, I MUST KNOW WHY. Even if that requires building a debug version of my entire stack, adding all sorts of traces, and wolf-fence debugging until I have a minimal fail case.

It's a real limitation; if I hit an undebuggable brick wall, I have no ability to attack the problem from a different angle. Luckily, there are few things that are fundamentally undebuggable.

But at a given sample rate, if I'm sampling at bit depth 2, doesn't that quantization error end up temporally shifting the sine wave I'm reconstructing?

I'm pretty sure that #2 isn't true; signal processing folks will be able to phrase this better than I can, but I think that if you have enough information to capture the waveform at a given frequency, you also have enough information to precisely place it in time - phasing errors are more likely due to quantization error, which is about bit depth, not sample rate. No?

I've scaled systems from 500 to 1.5 million simultaneous users, and this is the ONLY concise, salient explanation of performance troubleshooting that I have ever seen. Bravo.

I tried 7506's (I think?) and found them really bright and fatiguing - kind of the Genelec of headphones.

But as others have pointed out, you're optimizing for a different variable in the studio. First of all, you'd never mix or master on headphones unless you're testing to see how your mix sounds on headphones. So at that point, you probably want cans that translate well to "average" headphones, and it may well be that the Sonys do. Think about NS-10's, or even Auratones - they're not great speakers, they're just a common reference point that everyone knows.

And for tracking, you really don't want flat response; you want cans that'll reinforce the musician's ability to hear themselves, the headphone equivalent of a presence peak. Isolation is critical - no headphone bleeding. But the most important quality for tracking headphones is ruggedness; they are going to get abused, and they need to be easily repairable but rarely need repairing.

All of which is to say: being universal doesn't imply being the best-sounding or the most-comfortable; it implies being optimal for the needs of a recording studio.

"triple-dub".

Because responding to DMCA notices would take people, and Google always prefers algorithms over manual labor. I'm half convinced that the whole reason they're developing driverless cars is for Google Maps, the one Google property that requires a huge labor force.

I'm of two minds about consistency vs banks. On the one hand, yes, in the CAP sense, "consistency" is atomic consistency, and banks allow a form of eventual consistency. On the other hand, I'm not sure if the NoSQL sense of eventual consistency is strong enough for what banks need; how do NoSQL eventual-consistency models deal with conflicts that affect other tables? For instance, a quick Google shows that MongoDB offers "programmatic merge" - but would that also allow you to say "when merging my spouse's ATM transaction with mine in our checking account, also remove the spurious transaction in the bank's cash-on-hand account"?

Maybe I'm thinking too close to the metal; to get eventual consistency at a higher level, you still need atomic consistency at a lower level - even Paxos uses two-phase commit under the covers.

As for the partitioning, what "isn't wrong" is:

- He says the CAP theorem is historically irrelevant to relational databases, which is wrong, and that they have been "adapted" to provide high availability, which is kinda wrong, and then:

- He confuses "partition" in the "partition my database" sense (scale my database across multiple tables or nodes) with "partition" in the original CAP sense (do not permanently explode if a node goes offline), so he isn't even wrong - any multi-server database allows partitioning, by definition.

Also, I think you're misunderstanding that item on the wiki page; it sounds like Postgres-XC IS globally consistent, but that it can't yet support some important forms of consistency like UNIQUE constraints across nodes (you can only have a unique constraint within the same node). All nodes would see the duplicate rows, though, so it is globally consistent.

It looks like different people use different definitions of partition tolerance; the original meaning was:

"The network will be allowed to lose arbitrarily many messages sent from one node to another."

Which means that, if you have a network, you have partition tolerance, period.

But Stonebraker defines it differently:

"If there is a network failure that splits the processing nodes into two groups that cannot talk to each other, then the goal would be to allow processing to continue in both subgroups."

Great article here:

http://www.cloudera.com/blog/2010/04/cap-confusion-problems-...

As for two-phase commits, I'm not sure what system you've used that requires app knowledge, but (for instance) PostgreSQL does them automagically; you just do PREPARE TRANSACTION and COMMIT PREPARED, and if the transaction fails you need app-level error handling - but presumably you have that error handling even without two-phase commits.

Here's an article on Facebook's move to HBase:

http://www.facebook.com/note.php?note_id=454991608919

Of course you can change schemas on the fly. Just because ALTER TABLE goes ka-thunk on MySQL doesn't mean it can't be done in more robust databases.

I'm not sure what you think two-phase commits are, but they ARE atomic transactions. They are essentially "Everyone cool with this transaction?" "Yep!" "GO."

The CAP gotcha is that you already have partition tolerance - if you didn't, your database would go "boom" when a node went offline. So, really, it's "pick one".

And believe it or not, Facebook moved some stuff from Cassandra to HBase in part because of its stronger consistency model.

I can't even count how many mistakes this article makes. A random sampling:

- Relational databases were designed for a world where availability is unimportant, like transaction processing. Um, no. OLTP has four letters, not two, and the first are as important as the last. Tandem was providing five-9's systems in the '80s and '90s for ATM networks, lottery systems, airline reservations, credit cards, etc. Tandem is a fault-tolerant relational database in hardware.

- Up-front schema design is a poor fit in a world where data requirements are fluid: I don't think "up front" means what you think it means. You can change schemas on the fly nowadays; your schema design is no more up-front than your coding is.

- You can't have millions of columns in a relational database: True, and you wouldn't; you'd normalize that. This is an important difference, but not a disadvantage of relational databases, any more than saying "In a relational database, you'd join URLs with IP addresses, and maybe five other tables; this design isn't even conceivable in a NoSQL database."

- To optimize relational performance, you "do away with joins wherever possible": 1995 called, and it wants its MyISAM back.

- Two-phase commit is so obsolete, even banks don't use it: Of course they do. You still need a two-phase commit to make sure the other end got your data; whether "got your data" happens in the customer path or during reconciliation is a design decision. How, exactly, do you think they discover that you and your spouse both got the money?

- "relational databases were developed when distributed systems were rare and exotic at best." That's nothing; when Von Neumann machines were developed, we didn't even have transistors. Some legacy architectures keep on working.

- "absolute consistency isn't a hard requirement for banks": see above. Yes it is.

- "So the CAP theorem is historically irrelevant to relational databases: they're good at providing consistency, and they have been adapted to provide high availability with some success, but they are hard to partition without extreme effort or extreme cost." ... Wh... Bu... That's not even wrong.

- "consistency requirements of many social applications are very soft." I like the Facebook example from a recent article on causal consistency: I de-friend my boss and then post that I'm quitting. Certain kinds of consistency are in fact critical to social applications.

There are many good reasons to design around a NoSQL database instead of a relational one. This article provides fewer than zero of them.

I can't tell from the README - is your data fairly wide? I'm playing with using Postgres's new K-Nearest-Neighbor support to calculate similarity on 20D cubes, but I suspect my approach won't work well for an arbitrary number of columns (i.e. users x products) unless you first do some sort of PCA or SVD to narrow it down, and it isn't optimized for binary ratings at all. I started writing it up here: http://parapoetica.wordpress.com/2012/02/15/feature-space-si...

Then I'm confused. If you need a settop box to get encrypted channels, and the cable companies want to save money by not providing settop boxes, why are they lobbying for permission to encrypt the remaining basic cable channels? There's a leap I'm missing.

aka a "high concept" pitch (though "X for Y" is really just a subcategory of high concept).

I'm confused by the thesis of the article. Amazon isn't dominating online payments because if they supported OAuth, they could use their own one-click patent to put themselves out of business?

I read this as him _literally_ guessing what the size of the list was, not that there was a list.

As has been noted elsewhere, a Time reporter described a personal briefing as well. I think you're assuming that his article is a complete transcript of the meeting and any followup conversations, rather than a vignette.

TFA says the default security setting DOES run any signed app. The two non-default settings are tighter (App Store only) and looser (any app).

FYI, Office for Mac doesn't include OneNote, which isn't available on Mac.