andfarm

Also gone for unrelated reasons, sorry: https://files.dreamhost.com/

Just shell/FTP passwords. As noted above, panel passwords are fine.

We've got a mass email going out now.

We're not quite done investigating the issue and resetting passwords; once that's done, though, we will have a mass email going out.

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).

Input elements can have :clicked states... :)

Specifically, the "standard compression" version is MainConcept at 10 Mbit, and the "Raystream" version is x264 at 1.15 Mbit using the following options:

> x264 - core 112 - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=0 b_bias=0 direct=2 weightb=1 open_gop=0 weightp=0 keyint=250 keyint_min=24 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=22.0 qcomp=0.70 qpmin=10 qpmax=51 qpstep=3 ip_ratio=1.41 aq=1:1.00

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.)

Harvey Mudd doesn't have a masters program -- I'm pretty sure he graduated in 2008. I lived across the hall from him at one point. :)

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.

Also, it isn't encrypted. So there's that too.

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. :)

As far as I can tell, most or all of the one-bit errors on those are already registered by typosquatters.

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.

Which is enough for two to three thousand thick books. And I believe that, unlike Apple, Amazon will let you delete and redownload books at will.

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.

Harmless Javascript minification can be difficult to distinguish from intentional obfuscation. Packer in base62 mode (http://dean.edwards.name/packer/) is a good example.

> Any possibility to upgrade RAM?

Probably not; they're likely using a SOC with integrated memory.

We're currently taking registrations under COM/NET (Verisign) and ORG/INFO (Afilias). US is a third, separate registry (NeuStar), and we aren't currently a registrar for them.

You know, that's a really interesting observation. Having lived across the hall from day[9] in college and seen him play both Starcraft and poker, the intense concentration, and frenetic clicking, and split-second analysis involved in both activities are really not all that different. :)

So, comment spam tools? That's deep into the realm of "black-hat SEO".

Works, but kind of sluggish by comparison. (Odd that I'd find myself saying that about Chrome and Firefox!)

A lot of parsers do support numbers outside 0-255, though, and treat them as "packed" addresses. For instance, 127.0.1, 32512.1 and 2130706433 are all sometimes treated as alternate representations of 127.0.0.1.

As far as I could tell, that post was just about one specific SF project that had a vulnerable PHP CMS installed on their web space. It's possible that the more general problem of projects being allowed to install/manage their own software got leveraged into a larger exploit, though.

They're certainly available -- at least, in Mozilla -- but usability is poor. The most obvious issue is that there's no obvious way to copy a client-side certificate to another machine, making it incredibly awkward for users who use multiple computers (or, worse, who only have access to shared computers).

http://www.dreamhost.com/unlimited.html has details.