doing an English language search on google.de is kinda unfair. Also note that the hl param on google is set to german. Of course you get crappy results.

what's next? meta name="browser" content="nolink" to not allow deep linking? or linking at all? this is stupid.

You can download all the tracks you purchased from http://music.google.com/.

Yes but what about all of my tracks I uploaded?

Well data liberation doesn't say that they have to act as a drop box for you. If you have full control of your music to begin with to upload, that's pretty much liberated by the very definition of the term.

Well, you uploaded them in the first place, which means you had a copy at some point.

Don't delete that copy.

Well I was hoping to use Google Music as a safe place to keep my music instead of having to keep them on a hard drive some place.

Music Plus extension for chrome allows you to retrieve tracks, and I'm quite sure there is an equivalent for firefox. It's not automatic, but it's something

Overcommit was a design decision that seems wrong at first, but when taken with a wide viewpoint makes some sense. The motivating reason for overccomit is to make fork cheap. (the article even briefly touched on this). It's a trade off between the speed of spawning new processes (and threads) and ease of understanding how your system will behave in low memory situations. I think they made the right choice.

Another thing to note. The systems in the article were in trouble regardless of the overcommit, it's just that overcommit hid the problem and made it occur in a non-obvious place.

wait. It's still not clear to me that Twitter has succeeded as a business. Are they making money? It's not clear to me yet that they are.

Clever. But I find the idea of RouteFS more clever than the toy FS he built...

Applications of the same idea have been around for some time, e.g. Plan 9's file system (e.g. GUI elements are part of the FS, , bash's /dev/tcp/<host>/<port> etc., and indeed /proc's file system seen in Linux and, in a limited way, in Solaris.

Seems like no Linux app framework can be complete without reinventing its own virtual file system, with various syntaxes for paths to e.g. network shares but that are inaccessible when used on the command line, etc.

The point is that a FUSE filesystem is available from the command line and anywhere else, because it is an actual filesystem. RouteFS is a way of taking any virtual filesystem-like tree that you might find useful and making it available to the entire system as a normal filesystem, just as easily as you could describe the tree in any other form.

I know all that. I was bitching about how it seems like every layer of the software cake on Linux likes to design its own virtual file system.

have you tried rebooting?

Not yet. I was hoping to find a less drastic (and more educational) fix. I'm also a little worried that rebooting might make the situation worse since I don't really understand how FUSE works under the the hood.

I don't see any really compelling reason to have all that functionality shoved into one device. I like the idea of separating playback/record from storage.

I like the idea even better when the storage is in the cloud (with a possible local cache, would be nice).

HashMap (unlike treeset) itself doesn't provide an order guarantee. So can't you just grab the first element from the entrySet and use that?

But I think the bigger problem is trying to use a Map in the first place when maybe a different data structure will solve the problem better.

I of course didn't talk about why I'm using a map, but as an example: consider redis. It's a giant hash table, and it allows you to pick a random key.

Just because it doesn't make any guarantees about order, doesn't mean you'll get a randomly-selected element if you pick the first one.

Aho is also the "a" in awk.

brilliant, didn't know that! (and I do know who w and k are in awk fame!)