With this and the Humbe Indie Bundle, could it be? 2010: The Year of Cross-Platform Gaming on The Desktop!

Seriously, this is spot-on. I like to support gaming on the Mac, but I just got sick of paying the inflated prices for old games. Even an old title that would be in the $5 bargain bin for Windows, would sell at full-price for the Mac. So, I've mostly been playing PS3 games and downloadable indie games for the Mac. The situation with games on disc for Mac is ridiculous, with the exception of X-Plane, which isn't really a game.

Being able to easily migrate is awesome - and it means I might one day be able to easily move to Linux if/when it has enough applications to meet my professional needs, and bring my games with me.

In my experience, while Matlab is a great way to get started, the code you produce in Matlab tends to be difficult to port across nicely, even to Python, because Matlab just does stuff in such a unique and honestly, bizarre way. I agree, Matlab doesn't really do anything well in my opinion, hell I am a TA for first year Matlab classes at my uni and I hate every minute of it.

Well, a completely wrong post which is actually well written does deserve an answer. Here goes:

>>What happens if Steam goes offline?
>You get to play your games. Seriously, the servers were offline yesterday, and I was quite busily shooting people in the face.

Then my guess is steam was not offline. If you can't ping steam servers, you certainly can't log in, and thus play. And offline mode you say? You have to go online to activate it. I'm not kidding. Basically, if you can plan that you will be offline, that's okay; but if your connection dies for a day (or you end up stuck on the train), you can't play.

>>How is asking permission to play with your legally purchased toys good DRM?
>Fuck, I don't even know what this means. Start Steam-->Start Steam game != 'asking permission'.

It is the same thing as asking permission because they can refuse. For example (as already stated) if the internet is down, or if your country or account suddenly ends up on their naughty list for whatever reason in 5 year.

>How is we can take your games back at any time for no reason good DRM?
One's man 'no good reason' is another man's good reason. Provide some cases so we can judge on the merits, not your wild rantings.

Ok, he should have said "at any time for any reason". "Any reason" includes a lot of bad ones. Wether they already did or not is an other story (I'm pretty sure they did), but you would have to trust them a lot about the future.

>What happens if there's simply a screw up and you loose access?
Like, what, forgetting your logon details? That would just make YOU stupid.
Screw ups happen. It's a risk you should prepare for, by not accepting useless locks (so you can't loose the keys).

>You have no legal recourse due to the contract you signed.
Spouted like someone who's never had to sit through contract law classes. Leave the hard work up to the adults, mmkay?

Only the actual points need a rebuttal.

>You have no first sale rights without Steams approval.
Whoa! Something approaching a useful point. Yes, that's technically correct, but I could theoretically 'give' or 'sell' my Steam account to someone else, without any hassle from Steam, so I'm not sure how histrionic we need to be.

Good luck with that once you have 20+ games on the same account, which also has friends, counter strike clan, etc. Also the contract may forbid you to have more than one account (if it doesn't, it certainly might in the future).

>Steam is the worst possible DRM.
Spoken like somebody who does fuck all gaming these days. Ever hear of Securom? You know, the DRM that keeps getting front page articles here on Slashdot? Yeah, I think that'd win a poll of 'Worst DRM' by a landslide.

I agree on this one: steam is not the worst. It might be the one with the worst effect though, because of its widespread adoption (and the direct binding of the DRM with the game store).

> I understand this joke often gets +5 Funny, even though I don't know what it refers to. So here I go:
> No disassemble Johnny 5!

It's from a 1986 movie, Short Circuit. (There was also a sequel). Fun old family movie about an experimental robot developing a personality. In the second one, there are also bank robbers.

http://www.imdb.com/title/tt0091949/

DNA developing into a robot is the other way round, of course.

You said it; what a pathetic and ignorant method to use! But don't worry I'm sure it will never see widespread acceptance and your way, the "right" way will surely come to dominate on PCs across the land.

...are doomed to reinvent J2EE. Badly I confess that I haven't tried any of the frameworks mentioned by the parent. But I have had conversations with people who have, and here are some questions that I have for the folks who think that the people who came before them (and invented J2EE) are stupid:

1. Can your framework handle two-phase transactional commits when it interfaces to other applications?
2. How well does it support single-sign across apps deployed across different servers but behind a reverse proxy that unifies them under a single domain?
3. Can you cluster multiple hosting servers for your app to minimize downtime during app upgrades? Does your application sessions failover to the other members of your cluster correctly, if so?
4. Can you take legacy code and layer your app around it without needing to rewrite the legacy app? Can you do this even if the programming team who wrote the legacy app is no longer around?
5. When you discover that you are having intermittent glitches (slow responses / server 500 response codes /etc), do you (a) reinstall (b) upgrade to a newer version of your framework / OS / whatever (c) Troll the user forums for your product / framework and hope that someone has seen your problem before. (d) Pull three all-nighters reading the source code to your product / framework? [Hint. The right answer is (e) Put your product into a supported trace mode and get your vendor to support you]

IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice. After many years of observing the competitors to J2EE, I have yet to see a professional grade alternative to it.

From whence comes your bile at IBM? Just because SQL was invented at IBM, doesn't mean that its actually bad, does it? Anyway - I wasn't bringing IBM into my argument. What I was saying was based on what I know SQL can do, and what it can't do.

Au contraire.

While there are problems with SQL, 95% of its users are happy as a clam that it exists. The unhappy users are the ones who are pushing the boundaries of what SQL allows and those are the people who know SQL best. When you are writing SQL queries that span 200 lines of code, then, and only then do you begin to scratch at the limits of what SQL allows. Until then, you've only hit the limits of competence.

I've been working with SQL for over 20 years now. I've worked with applications that didn't use RDBMS's. Some of them used flat files. Some of them used hierarchial databases. People who haven't had the same sort of experiences, haven't come to the realization of why SQL was invented - and that results in then making ill-founded statements like "SQL is absolutely the worst database query language ever invented". Utter tosh. SQL has its problems, but its one of the best. That's why it has left its competitors in the dust of time.

I look around at all the frameworks that have evolved to not do SQL (EJB-QL, Hibernate, etc) and I laugh. None of those languages come close to handling the same breath and width of problems that SQL can be used to solve. Whenever I see advocates of these frameworks all puff up with fervour, I feel like shaking them and say "Your emperor has no clothes!". The list of problems these frameworks can't solve is so huge that one wonders why anyone works with them at all. But I suppose, there are plenty of people who work for small businesses who haven't encountered the kind of problems that big enterprises have.

The parent poster that I'm responding to has apparently had an problems porting SQL code. But guess what? Even on the unix platform, applications written in C have had trouble being ported from one Unix to the next. People have worked around it. Nobody goes around arguing that "C is absolutely the worst programming language ever invented".

I can't think of any IBM product on the "distributed platforms" (i.e not mainframe or i5OS) where the fixpacks are not available for free.

That's nonsense. The "REAL" backup clause also applies in the case of a hard-disk based backup. You can't really know that the data being backed up will still be useful unless you read it back periodically. All things being equal, the data integrity of tape media over the long-term outstrips that of hard disks. Storing hard disks safely over the long term and handling them requires more care than a tape.

In addition, a lot of tapes come with a read only hardware setting that one needs to consciously move to the read-write setting - which is very useful for data archives. If you try to overwrite a hard drive based archive with new data, there are no such safeguards available to you.