|
|
FWIW, the GTX 680 supports up to four displays per (single GPU) card. I haven't tried it yet, but I would expect it to work much better than the 4 monitors across 2 cards support that one was limited to in the past.
Multimonitor across multiple cards has never been stellar in any OS, probably because it's a very niche use case, but multimonitor on a single card is a very common use case.
ALSA's default config since the early 2000s has allowed multiple simultaneous sounds to be played without any specific application support, even on hardware that doesn't have hardware mixing.
Unfortunately, somebody got really drunk awhile ago and thought PulseAudio was a good idea, and now most distros ship with broken sound configs again. I estimate it'll be a couple years until we're completely past the damage that PA has done, and we'll only be back where we started at best.
To this day I have no idea what problem PulseAudio was trying to solve, but I'm pretty sure it was a net loss.
Especially any sort of OpenGL, which doesn't work over the network.
Wrong! OpenGL works over the network, in fact it was designed to.
OT: The register page in your sig is broken:
Fatal error: Class 'database' not found in
/home/rflowers/landofmyriad.com/lib/class.formelement.php on line 3
Taskbars are always set to autohide, so I don't see how this helps.
Monitor options have steadily gotten worse over the last 5 years or so. We were making great progress and then somebody decided that shortscreen (16:10) was the new way to go. Then, not long after that, somebody decided that shorterscreen (16:9) was the new way to go.
Luckily, I bought two 1600x1200 20" monitors right around the time progress stopped and they've remained top of the line ever since. I'd love higher resolution (note - not larger, 2x 20" is perfect, neck would get sore looking at 2x 27" or 2x 30") displays, but they don't exist for under $1000.
Oops, totally misread your summary, I thought you had several terabytes of storage needed rather than 35G. Anyways, the rest still applies, but you can buy a cheaper server with less drives.
That's an awful suggestion for this purpose. Linode is great, but charges a fortune for unusually large storage/transfer needs. Their biggest Linode at the moment has only 800G of space and 2T of transfer (and 20G of memory) for $800/month. That's going to be way overkill on the memory and huge underkill on the storage and transfer, and would already blow the budget.
Totally agree, once you get into this type of scale, you want to buy your own servers and colo them.
For a random example (not an endorsement, I've never used them before), Pair has 10U of space with 5 mbit bandwidth for only $400/month. Throw in a 2U server (~$3,000) with 12x 2T 7200 RPM drives (12x ~$150) in RAID 6 for 20T of usable space. Double the drive cost if you want "enterprise" drives. Shop around and I'm sure you can get better deals, these are just ballpark figures. I have no idea what kind of IOPS you need out of your storage, but it's easy (and much cheaper) to adjust your hardware to suit your needs when you own it.
The only situation where I wouldn't recommend managing your own servers is if you simply don't have the relevant domain knowledge AND you have the money to waste on managed hosting (ie, time is more valuable than money).
If Javascript were compiled into machine code before being sent to the client, it would be exactly 0% more useful for security related purposes.
Wrong; machine code is much harder to reverse-engineer than source code or minified code. Not impossible by any means, but it raises the bar; security-through-obscurity really does work, and is better than nothing at all, though it's obviously not something to be relied on if you can help it.
You're right, I should clarify. If Javascript were compiled into machine code before being sent to the client, it would be even worse for security most of the time, because a false sense of security (source code obfuscation in this case) is often worse than none at all. It lulls people into making bad choices that they may not have otherwise made... "Hey, nobody will ever figure out my Javascript code, therefore I can cut my workload in half by only doing the client side validation and skipping the server side validation! Great!", or "Hey, since nobody can read my Javascript, I'll just send down the whole database with every request, it'll be so much faster that way!"
I would also point out that in this particular case, reading the Javascript (regardless of how easy or difficult that is) is rarely going to be the preferred way of exploiting the system when you could simply peek at the network stream and see what happens when you push buttons.
In actuality, Javascript (ran in the client's browser) is far from useless for anything security related. Say you're implementing a login page. The naive approach would be to have a login and password field and send that over the wire back to the server in plain text.
Ok, I guess we need to start defining what we mean by "security". What you're describing is a situation in which the server implicitly trusts the client, but doesn't trust anyone that may be in the middle snooping on the communication. What I was talking about in the context of this copy-protection stuff is a situation where the server does not trust the client, and wants to limit how the client uses information the server sends it.
No, I'm describing a situation where the server does not need to trust the client and the client does not need to trust the server (in the ideal case). The client *proves* itself every step of the way and visa versa. It should go without saying that the actual format of the data still needs to be rigorously validated after it is received and before it is used.
The only way to limit the way the client uses information you send it is to limit the information that you send it.
* I was looking at free shopping cart software a while ago and found one that was implemented entirely in Javascript. It was fast as hell of course, and very nice-looking, but the problem was that, being Javascript, it was trivial for anyone to make up any order they wanted and send it to your server. You'd either have to implement a bunch of logic on the server to make sure your orders are legitimate, or be sure to catch them manually (easy if your volume is extremely low, not if it's higher). The whole thing just looked like a bad idea because it was trusting the client so much.
You have to implement a bunch of logic on the server to validate the order no matter how you send it to the server. Whether you construct the shopping cart one item at a time (dumb page with a bunch of buttons that all do separate posts) or all at once (fancy Javascript page) matters very little if at all with regards to the complexity of validating the order as a whole. The reason why it doesn't matter is that regardless of how you hope the data gets to your server (users clicking buttons on your page in a browser), it can also come from sources you may not be hoping for (nefarious users constructing their own requests directly).
What does impact the complexity of the validation is the design of the data that you choose to send back to the server from the client. You could, for example, send back the product name and the price. This would be monumentally stupid, but I'm sure someone somewhere does it. At this point you need to match the product name to the correct product in your database so you can pull out the rest of the details for it, and then you also need to validate that the price that was sent matches the price that you have stored. God help you if you ever decide to update the name of a product, or use an abbreviation of the product name, or offer your site in more than one language, or ever change the price of a product, or dozens of other factors, and that's not even touching upon the issue of validating the freeform text for further use (embedded nulls, unicode, lookalike characters, typos, escaping, encoding, etc). If you were smart, you would send the product id only, which is probably a positive integer and thus extremely easy to validate and never needs to change, look up the rest of the details in the database and you're done.
"It's a summons." "What's a summons?" "It means summon's in trouble." -- Rocky and Bullwinkle