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.

This is a classic case of bad defaults. Yes, you will always have a trade off between performance and security, but going for either extreme is bad usability!

People expect that, without explicit syncing, the data is safe after a short period of time, measure in seconds. The old defaults were: 5 seconds in ext3, in NTFS metadata is always and data flushed asap with but no guarantees. In practice, people don't lose huge amount of work.

What happened is that the ext4 team thought waiting up to a *minute* to reorder writes is a good idea - choosing for the extreme end of performance.

My question is: WHY? Does it really matters to home users that KDE or Firefox starts 0.005 seconds faster? Apparently, the wait period is long enough to have real life consequences even with limited amount of testers, imaging what happens when it gets rolled out to everyone. On servers, it's redundant. Data is worth much, much more than anything you hope to gain and SSD's, battery backed write cache on controllers and SAN's have taken care of fsync's() already. If you run databases, those sync their disks anyway, so you just traded a huge chunk of reliability for "performance" on stuff like /home, /var/mail and /etc.

The "solution" of mounting the volume with the sync everything flag is just stupid. Yay, lets go for the other extreme - sync every bit moving to the disk. Isn't it already obvious that either extreme is silly?

Just set innodb^W ext4_flush_log_at_trx_commit on something less stupid already, flushing once every second shouldn't kill any disk. Copy Microsoft for config options:
* Disable flush metadata on write -> "This setting improves disk performance, but a power outage or equipment failure might result in data loss".
* Enable "advanced performance" disk write cache -> "Recommended only for disks with a battery backup power supply" etc etc.
* Enable cache stuff in RAM for 60s -> "Just don't do it okay, it's stupid."