Take a look at decapod-project.org for a complete system. Note that software dewarping is quite a hard problem, but it is part of decapod.

Modern web frameworks like Cobol on Cogs already do burned-in CRT emulation and various other effects too. ;-).

Er, what do you think Sony's "core business" is? Hint: it's not TV sets.

It sounds like you're just trying to save some server resources, not run an ultra high security operation, and that you probably DO want to let legitimate users access the site even when they're travelling. The simplest thing, it sounds like, is to just ask people to enter their zip code when they register. Explain that it's a site for a certain locality and they shouldn't register if they're not from there. If they enter an out-of-area zip code, give them an error page explaining the same thing again. Don't tell them the "valid" zip codes. Yes they could look them up if they're motivated enough, but in that case you probably want to let them in anyway, i.e. maybe they used to live there and still have connections to the area, that sort of thing.

All the stuff about IP geolocation seems like a waste of resources in this context.

to these damn companies anyway? Facebook, Myspace, Livejournal and all the rest of them. The whole thing gives me the willies. Much better to get plain old web hosting and pay for it and control it yourself. Anyone remember Facebook's "Beacon" program? It's one insidious scheme after another. After this TOS stuff, it will be something else.

There is a very obvious anonymous payment system run by the US Treasury and its counterpart organizations in other countries. At registration time ask for the serial number of a one dollar bill, and require that the bill be sent by snail mail to confirm that it is real, and to help with site expenses. No names or return addresses are required and no spammer will go anywhere near that.

Oh I see what you mean. The following approach may be worth experimenting with, but no promises: 1) Configure one browser the way you like it, using the method described above. 2) Look in your .mozilla/firefox/(profile name) directory for a file called cert8.db 3) Push that file out to other desktops in your installation.

In firefox 3.0.5:

Edit -> Preferences and select the "advanced" (gear) icon. From there, select the "encryption" tab. Under that tab, click "view certificates" and then "authorities". Select any CA that you want to remove and click "delete".

and I think we know better than "no one will ever want more than 640K" or 4GB as the case may be. The latest trendy accessory is ultra expensive ($25/GB) Intel X25-E flash drives and a lot of the motivation for buying them is inadequate ram capacity in the host computer (since the flash disk costs more per GB than RAM which is 100x faster, though volatile).

Yeah a lot of people are still running 32 bit OS's, but almost all desktop hardware now being shipped is 64 bit-- we're in something like the tail end of the Windows 3.x era. I think most serious users will run 64 bit OS's pretty soon. The Mac Pro uses FB-DIMM and has 8 sockets (wish it had 16) and for a big class of data crunching tasks, what matters most is the amount of ram you can throw at it. The recent collapse in ram prices has been amazing. If enough sockets were available we could fit out $5000 boxes (think of a fully loaded Dell Precision or Mac Pro, not exactly a mass market consumer pc, but not a high end Sun server either) with 128GB or maybe even 256GB. That really extends the range of problems you can attack. But, the bottleneck even in server boards seems to always be ram sockets.

The Nehalem/i7 uses DDR3 which is a lot more expensive per GB compared to DDR2 and not available in as high capacity. It has more bandwidth but its latency (which matters more) is about the same. The usual desktop mobo is limited to 2 dram modules per channel. DDR2 boards usually have 2 channels (4 sockets max) while DDR3 boards have 3 channels (6 sockets). But 4GB DDR2 modules are around $100 (link) while DDR3 currently maxes out at 2GB. So you can populate a Phenom or Core 2 mobo with 16gb of ram for $400 but you can't put that much on a normal consumer i7 board for any amount of money. 2GB DDR2 parts are a lot cheaper still, you can put on 8gb (4x 2gb) at around $15/gb, $120 total. Right now a 2gb DDR3 part is $50-ish, 3x as expensive (link). It helps that you can put 6 of them on a board (12gb total, $300) but you have to take the cost difference per GB into account with 2GB parts, and comparing with 4GB DDR2 parts there is $/GB parity but lower total capacity (4x4gb vs 6x2gb). And of course when 4gb ddr3 does come out, it will bring a welcome increase to 24gb total capacity, but it will be WAY expensive for quite a while (the 4gb ddr2 modules that are $100 now were $500+ for most of this year).

I just don't understand why there aren't more consumer boards with a lot more sockets, using FB-DIMM or registered DDR. You have to go to server boards for that ($$$).

In this case I think it's the cops who are exploiting a weakness (that most cell phone users are identifiable unless they take special precautions), not that anything is wrong with cops using what they can under the circumstances. But, as a general matter, private communications are a GOOD thing. If we have a situation where a criminal wore gloves to avoid leaving fingerprints, we normally wouldn't say they exploited a weakness of the fingerprint system that needs to be plugged by outlawing gloves.

> Also I think the strysand effect may well be helping the sales skyrocket.

The version of the record with that picture has been out of print for many years. They switched it over to a picture of the (fully clothed) band. The record itself may well be out of print by now.

I think most would consider Haskell to be a purely functional language even though it has some types that are implemented with mutable data for efficiency under the surface. For example, the ST monad is implemented with a mutable cell, unlike the State monad which is purely functional. In reality they do the same thing, you could implement ST's semantics using State, it would just be slower. Same thing with STArray and so forth. I actually haven't used ST so far, but I'm still a relative Haskell newbie. I have the impression that Ocaml is easier than Haskell for imperative programmers to get accustomed to, but I haven't tried it. Haskell certainly has its notorious learning curve. But, it seems to be the focus of quite a bit more interest and development activity than Ocaml these days.

1. In fact everyday programmers do prove things about their programs all the time. Not every last detail of the semantics (that is very difficult) but they rely very heavily on type safety, which is enforced either by a static type system (like in Java or Ada) or by automatic runtime checks (languages like Python). Languages like C, which have leaky type systems AND no runtime checks, are generally full of bugs that end up getting exploited by viruses. Almost every security bug we hear about, and the spam botnet that arises from the exploit, is caused by some type error (usually unchecked array overflow) in a C or C++ program. Functional languages (not exactly inherently, but more as a cultural matter among the designers) treat type systems as lightweight theorem proving schemes. So Haskell's type system is FAR more advanced than what you'll find in something like Java.

Let's say you have a few thousand (name, address) pairs and you want to be able to quickly look up a name to get the corresponding address, to add new names, etc. In imperative programming you'd probably use one of the mainstay data structures of CS 101, the good old hash table. To add a new name, you hash it and go and poke that address in the table to record the entry.

Well remember that stuff about values in functional programming being immutable? Right, no hash tables in functional programming. You'd instead use something like an AVL tree or red-black tree, that let you create a completely new structure that shares most of its content with the old one, except that the new one has this extra node. Of course FP language libraries come with modules for making those structures, and in practice you can use them at the API level sort like how you used to use hash tables, but they are completely different underneath, and if you want to program them yourself you are going to have to learn a lot of very basic techniques from scratch all over again. Chris Okasaki's book "Purely Functional Data Structures" is a good place to learn about this stuff in detail.

Even more basic: the good old "for" loop, which updates an index variable each time through. Whoops! You can't update the index in a functional language, so there's no "for" loop. You instead use recursion, or a "higher order function" (function that operates on other functions). So instead of

      for (i = 0; i < n; i++) xs[i] = f(ys[i])

You'd write something like

      ys = map f xs

("map" takes a function f and a list of values xs, applies the function to each item in the list, and gives you back a new list). There is also a "list comprehension" syntax that you might know from Python:

      ys = [f(x) | x <- xs]

but for complicated functions you end up having to use higher order functions and recursion explicitly. You really have to think a lot harder to program 20 lines of Haskell than 20 lines of C. But those 20 lines can do an order of magnitude more.

(Aside:) In case you were wondering, yes, you can implement traditional hash tables and other mutable structures in functional languages, and there are times when it's necessary, but it's comparatively a pain in the ass and you give up some of the advantages that had you programming functionally in the first place. Here is an article about someone's experiences switching from a mutable structure to a functional structure in a large program, and the headaches the functional structure solved:

http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html