Embarrassingly... no. Our login/authentication system was written in 1999, and it shows -- we store panel login passwords using symmetric encryption, and send out the decrypted password when you request it.
Getting this fixed was already on our to-do list. This incident has moved it up to near the top of the list (competing with a few other security-related tasks).
We're currently in the middle of resetting passwords, machine by machine. If your old password has stopped working, that means we've gotten to the machine that you're on, and you're safe to reset it through the panel.
Panel passwords are safe, BTW. The only passwords that we believe may have been compromised are UNIX user passwords (e.g, FTP/SFTP/SSH users).
Specifically, the "standard compression" version is MainConcept at 10 Mbit, and the "Raystream" version is x264 at 1.15 Mbit using the following options:
It plays on iPods and other iOS devices. Other than that, not much -- FLAC's compression ratio is a bit better on average, and more non-Apple devices support it.
The release of this code isn't really all that exciting, as there's already a free reverse-engineered implementation in libav. (It might not support all the modes described in this source release, though.)
It's almost certainly based on the author's experience in Harvey Mudd's CS 151 (Artificial Intelligence) course, in which developing a Mancala AI is a standard project.
SCTP is at a different layer of the network stack -- it's a replacement for TCP, not for HTTP. As such, it's much more difficult to deploy, as it currently requires a kernel extension in most OSes, and can't traverse most firewalls.
Pages' full-screen mode is relatively new -- as far as I'm aware, it wasn't added until the Lion update. Scrivener et. al. have had the market to themselves up until now.
That being said, the fullscreen mode in Pages actually seems like a pretty nice compromise between features and non-distraction. Apple's obviously been taking some notes. :)
I don't think it's actually any more powerful in that regard than, say, <iframe> tags. If your application lets users perform destructive actions with a GET request, you were already vulnerable.
aufs isn't mainline, and will probably never be mainline, because it's ~27,000 lines of poorly documented and often buggy code, written by a single maintainer in a style that doesn't really mesh with the rest of the kernel.
Speaking from experience, there are a lot of edge-case bugs remaining in aufs. It's usable enough for livecds and whatnot, but trying to use it on a server is a recipe for disaster.
Probably worth noting that the vertical tab UI you end up with looks pretty weird (on Mac OS, at least), as it's literally just moving the existing tabs over to the side without changing the graphics at all.
I'm having trouble thinking of any situations where you're free to use any alphanumerics, but you absolutely can't use anything else. The closest thing that comes to mind is DNS, and that's a 36-character set, not 62.
Ascii85 (http://en.wikipedia.org/wiki/Base85) uses a similar concept, but using the majority of the printable ASCII characters. It gets a hard-to-beat 20% expansion on binary data (4 bytes in 5 chars) without requiring bigint math.
Far worse. As defined, you can't write a parser for "tagged netstrings" without:
* Infinite lookahead - the type for a tagged netstring doesn't appear until the END of up to 100 MB of contents.
* Large intermediate memory usage - a string of the form 9990:9985:9980:9975: <...> ]]]] may consume a very large amount of memory for substrings during parsing.
* An int() implementation which exactly matches Python's.
* Ambiguity.
Bencode (http://en.wikipedia.org/wiki/Bencode) has been around much longer, and is considerably better thought out. There's no reason to not just use that instead.