Emails do not always come from humans.

A good deal of the thanks for registering / receipt / mailing lists come from no-reply@whatever.com, and the body of the email always includes a way to contact a human being if needed. That's quite a bit different from "number unknown", you've just put your own email address in our system - with a please call me back note.

As much as I hate spam, I hate overzealous gateways on the internet more. Earthlink for example refuses to receive mail without a valid return address (so no-reply@ must respond to RESP) and sends you one of these:

I apologize for this automatic reply to your email.

To control spam, I now allow incoming messages only from senders I have approved beforehand.

If you would like to be added to my list of approved senders, please fill out the short request form (see link below). Once I approve you, I will receive your original message in my inbox. You do not need to resend your message. I apologize for this one-time inconvenience.

Click the link below to fill out the request:

There's no way I'll waste my time filling in that form, so I've added big warning on the registration page now - sorry users of a overzealous ISP, please disable your spam filter if you can or just use another email address to register from.

Try a processor with AES-NI. Tom's Hardware got 3570MByte, or 27Gbit/s out of a single Intel i5. With the new Xeons in March, you'll get x3 cores, x2 sockets in a single system.

What I don't get is how you can have such a high requirement for bandwidth but not the budget for enough hardware to just bruteforce this - even a single gigabit connection worth of traffic costs much more than a stack of 1u servers every month.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.

Hmm, can you explain why? I haven't worked with Rails much, but in Django, if things are too slow like in a really complex query spanning so many tables that the PostgreSQL optimizer chokes, you can hand optimize it easily by either rewriting how you specify it in python, breaking it up into multiple statements. You can also choose to retrieve the data as plain tuples or map/dicts if you need to fetch thousands of rows (100k+, I've no problem with 20k/query the normal way at all). If all fails, plain sql is just 2 statements away, with an easy way to turn the results back into objects.

A good ORM recognizes that there are situations that falls outside of the common/simple use cases and should assist you in the harder things, not work against you.

No it isn't.

PayPal isn't just a way to pay for stuff. It's a cross country and currency method to pay and it has an extensive list of options to integrate it with your front and backend. For example, we use it to: receive money for subscriptions, apply the applicable VAT rate according to user location and hook into the payment system for direct activation of accounts with IPN. Especially the last thing is a killer - I haven't seen any PayPal "alternative" to do that yet, and while integrating with my bank with a merchant account is probably possible, the monthly fee plus transaction cost is much more than just 2.5% + 0.30ct per transaction.

I'd love to see alternative for PayPal, but so far, nothing matches it in flexibility and reach. Most PayPal killers are a joke, the easiest way to identify that is to check the developers section. Instead of hundreds of pages @ PayPal describing everything in detail plus a sandbox, the Gunpal one is a forum with 4 posts? I rest my case.

A quick comparison:

iPad: iPhone OS. T91MT: Windows 7 home premium included, runs any other x86 OS.
iPad: No multitasking. T91MT: Yes. Even better with a $40 upgrade for a 2GB stick of ram.
iPad: Safari only. T91MT: Firefox and Chrome for me, oh, and it has flash too. IE is also an option but noone uses that :P
iPad: App store only. T91MT: Anything x86.
iPad: Has notepad. T91MT: can run the full version of Office / Onenote, Windows Journal is free. Best hand writing recognition, has math support.
iPad: SketchBook Mobile. Finger only. T91MT: SketchBook Pro, Corel Painter, Inkscape and lots more. Has stylus, only lack a pressure sensitive pen.
iPad: Dockable keyboard. T91MT: Convertible tablet.

After a few weeks of serious use, I must say that while having a touch screen is a major plus, you won't be entering a lot of text with the on screen keyboard. Seriously, even a longer url can take a while to write with tapping letters or writing and correcting letters, and complex passwords have a random chance to fail. I only use the tablet mode during note taking, browsing the read-only web, watching videos and reading pdfs in full screen mode, the speed difference in text entry is just too large. Be ready to bring the wireless keyboard with the iPad all the time.

Because using the right tool for the right task is an essential part of software development.

Java is a silly example for your situation, but if you work on a shell regularly, a mix of bash / python / regex skills will get your job done much faster. People who can master new skills relatively easy win the "breath of knowledge" contest, and it's those I'll be looking for, or we'll be left for dead when anything changes.

Tools for embedded systems don't change that quickly, but in web development, we went through PHP 4, PHP 5 which is basically a whole new language to a combination of python and java servlets, and evaluated all other promising options. Being extremely good in a single thing but nothing else means you're out of a job in a few years.

You raise a few good points, but really, hosted apps aren't all evil, and not everyone is that distrusting. Google Apps for Business has a long list of clients who depends on it, and there are enough businesses 'living on Sharepoint' on their intranet.

HTTP is just another protocol, it's not better or worse than a proprietary one, just different. And with all of them, if you lose connectivity to the server for whatever reason, you're doomed.

Err, $1000 doesn't buy a lot of developer time here. Even with a cheap, small software developer it won't last more than 3 days x 8 hours. I doubt that anyone can write a decent custom coded solution on that budget, you're better off with a default installation of a shopping cart, paid or free.

Sorry, but it doesn't work that way. As far as I know, none of the decent SQL engine choke on it, although I'm not sure on Access :P

Also, a lot depends on the size of the dataset and other parameters in the where clause. Real life example, with len(r) = ~1M and len(g) = ~20k: select * from core_report r, core_guild g where r.guild_id = g.id and g.id = 7. With this query, postgres executes it as: scan core_report_guild_id index, look for id=7. Then, lookup g by primary key and join it in a nested loop with loops=1. Without the g.id = 7, it executes as: table scan g, hash it, table scan r and join the two with a hash join. Note that the query planner switched from fetch by primary key, which is O(log n) * n rows -> O(n log n), to table scan x2, O(n), but with a much lower actual cost because walking a BTree isn't cheap. It also ordered it so that only 20k rows get hashed and copy-pasted into the main dataset, not the other way around. That's the advantage of using a proper DBMS.

You can pry PostgreSQL from my dead, cold hands. It's just so much easier to do meaningful things in a relational database, and until you hit the db-size > largest SSD (used to be RAM) you can buy limit, there is absolutely no reason to limit yourself to glorified tuple stores and hash tables. Okay, sometimes, ORM's can be slightly too eager to join stuff (causing queries like this one), but it's easily fixed by rewriting the line executing the query. Or just ignore it, even that monstrosity (1 index scan, 1 fetch-by-id loop, 3 full table scans) took only 1s max - who cares on a homepage/intranet/most websites.

Use fixed point numbers? You know, in financial apps, you never store things as floating points, use cents or 1/1000th dollars instead!

Computers don't suck at math, those programmers do. You can get any precision mathematics on even 8 bit processors, most of the time compilers will figure out everything for you just fine. If you really have to use 24 bits counters with 0.1s precision, you *know* that your timer will wrap around every 466 hours, just issue a warning to reboot every 10 days or auto reboot when it overflows.

Parent meant Single-frequency network with single channel multicast - several transmitters simultaneously send the same signal over the same frequency channel. It's way more efficient than what we have now - adjacent senders cannot use the same frequency as it causes interference. For example, on FM here, 101.20 and 101.50 is the same channel, but from different towers - one covers North-Holland, other South.

Lets have your grandma walk down the street, get mugged, break her hip and be traumatized. How many CCTVs would you be willing to put up to reduce the chances of that ever happening again? This privacy thing is getting incompetent, when you're in the public.. you're in the public. Unless someone has CCTVs pointing into your house. Appreciate the fact that if someone knifed you in the street, you have a better chance of catching that person

This really makes me doubt their ability to benchmark / scale things properly. In the article, he sounds like facebook is completely CPU bound, and yet he's slamming the latest generation server processors by Intel / AMD?

From all the benchmarks I've seen, like Anandtech's and from personal experience, web servers scale pretty much linearly with clock speed * IPC and the amount of cores present in the system. The addition of HT is good for another 20% throughput.

What they need to do is to look at their setup, and make sure there isn't another bottleneck - have you spawned enough threads and processes to utilize the system completely? PHP may be "thread safe", but that usually means that there's a huge lock around everything that could be dangerous and one process refuses to use more than 100% cpu on 1 core, so serve it with apache-prefork + load balancer + separate static file server. Same thing for Python - fork off more copies via mod_wsgi even in threaded mode, as many as you can afford within the available RAM, or the Global Interpreter Lock will limit the CPU usage to 1 core.

If you have setup the environment well and there are no other bottlenecks, web services scale perfectly with the available CPU power. And that has increased by an insane amount for the Xeon 54xx to 55xx, it's almost doubled the performance in most server apps (OLTP, VM), but even the PHP test case which failed to scale to 16 cores in a single process was good for +39%.

It's an older chipset, but the Intel X-38 based motherboards accept ECC Dimm's. The price premium? 5 euros per 2GB, I've installed 4 of them in this system. As for something more recent, the X-58 Nehalem boards are ready for ECC, but to use it you need to install a Xeon.