Consider the state of network technologies 10 years ago. There is so much that can be done in the last mile by actually deploying fiber, combined with up and coming high speed switching speeds that I don't think this will be a problem long.
Whether people want to invest another couple grand on a new display, that's another thing.
What they *can* do is put that kind of resolution on desktop displays. Please, enough with the "1920x1080 is high resolution" bullshit. We all had the ability to do 1600x1200 on CRTs over a decade ago.
It's definitely an interesting game, but I found the controls particularly horrible. I understand why they are the way they are. Going from near light speed to a dead stop without any deceleration is rather unrealistic and vise verse. However, from the perspective of it being a "game" it was downright annoying.
Great concept, though, and definitely an interesting learning tool. It'd be even more fun if one could adjust the variables directly and and explore the consequences of those variables more deeply.
I'd say this:
1) It would be money foolishly spent as it would probably negatively impact the value of the property more than improve it
2) $10k to $20k is chump change for any significant remodel.
Because MySQL uses threads. It doesn't fork() to serve more requests, like PostgreSQL does
But there is a huge difference.
For MySQL, the database primarily serves the application. The boss is the app developer who gets to tell the db (through the app) whether to treat zero dates as valid or not, or whether 2009-02-30 is a valid date. The app dev is king. This works well enough when there is only one application writing to any given relation (many readers is not a problem there because the writing app is king). But it doesn't work well as a data centralization and management solution. If you have 20 apps writing to the db and they may all be using different sql_mode settings, that is going to be a mess if they share relations.
For PostgreSQL, data is king. The applications consume managed data. The DBA is the one who gets to make the hard calls and every app developer gets to live with the decisions made. MySQL is thus a bottom app tier while PostgreSQL is a data management and centralization solution. They are *very different* and if you have 20 apps sharing the same relations, PostgreSQL will be far saner because multiple readers do not have to tolerate eachothers' sql_mode settings.
I am starting to plumb the depths of PostgreSQL object-relational capabilities and wow, these are incredible. Not quite as impressive as DB2 or Oracle but I suspect that once people start realizing how awesome this is, they will get needed facelifts.
Well typically the installation is run as a root user (it doesn't have to be) because of file permissions considerations. However, it runs as a non-root-user and will actually fail to start if you try to run as root.
However there is absolutely no reason you can't run initdb as any user you'd like. you can't set up the startup scripts as a non-root user though for obvious reasons.
Anyone else notice that the cost for just *3* of these things is half a billion dollars, assuming no cost overruns?
Garbage In -- Gospel Out.