Have you tried OpenOffice on Win2k/XP? I tried it and recall it was pretty decently speedy - mind you this was a while ago, so my memory would be faulty. These days I use Office XP, despite the feel-bad MS factor, since I have lots of document exchange to do with Windows users, and I don't want my files to be imported "almost right".
That's how it's supposed to be. The problem is that in practice, I've seen cases where the "emulation" of a vertex shader in CPU didn't work properly (a DX8 vertex shader that ran fine on GPU, but had weird problems on CPU). The solution was a line-for-line port to C++ of the vertex shader, and having a separate execution path for non-VS supporting cards. In short, a big pain in the ass to program for.
You may be right, but if LinuxGazette existed and pre-dated SSC's involvement in the project, how do they have a right to the trademark? This is the problem with these kinds of informal relationships. My guess is that SSC does rightfully own LinuxGazette.com (the domain) because they registered and owned it and provided hosting on behalf of the LinuxGazette publication which they helped sponsor and were involved with for several years. But they can't assert ownership of the trademark over the people who started the publication without evidence of contractual transfer of ownership of the rights to trademarks beyond their registration of a domain name in 1997, period.
Well, the first problem is that all trades are pretty much temporally dependent for a given instrument. So you basically have to back out all the bad trades made after a point in time. Which is essentially what was done in this case - the trades *were* all cancelled. Keeping a real transaction open would be prohibitive and silly, since you want to design a system where these kinds of fuckups are very rare and manual.
Unfortunately, people don't seem to understand the real problem here. The problem is that people make offsetting trades in other markets, that are built on other systems, to lock in profits in the primary market. This story was about traders who sold options contracts to lock in profits on the stock itself. The trades on the stocks were busted by NASDAQ, but the options trades can't be backed out of, they are in a separate market. Thus the trader gets fucked. Having a transactional rollback capability on the NASDAQ wouldn't help here, it would have to encompass all the other markets people might trade in.
Mind you, I would think there would be legal recourse here based on contract law. The buyer entered into an option sale contract with reasonable reliance on the NASDAQ's "promise" that they bought the stock at a low price. Promissory estoppel against the NASDAQ, or against Archipelago? I don't know, sounds to me like an interexchange issue that needs legal or regulatory collaboration more than it needs a technical solution.
Depending on the type of product and market, they may be conducted on a single system, or rather, an exchange may handle all matching and transaction through a single system. Certainly futures exchanges do this, because they sometimes need to handle interproduct dependencies - dependent products like spread contracts that are actually tradable instruments in their own markets.
But you're generally correct, in a distributed financial marketplace where trades happen in many places and there is no central orderbook or matching system, it's impossible to coordinate large scale transactions via 2PC or any other distributed transaction model.
Plan the features and requirements of the software. Don't plan "enterprise architectures" and sit for hours of useless meetings with people who have NEITHER domain expertise NOR software expertise. I've seen pigeon management-style execs (you know, the ones who fly in and shit all over a project) insist on their personal "project manager" or even themselves come sit in on every single project meeting where a new system is specced out (and this exec was the President of a large financial institution, not some midlevel schmuck). His personal "project manager" was not really an experienced project manager, certainly had no technical background, and had absolutely no domain knowledge of financial systems. She was there to parrot information back to the President so he could come do his pigeon-style management after every project meeting (you know, come and shit all over it with brilliant suggestions like "hey, I know this is all in 'Java' right now, but I thought maybe we should switch to.NET, since I was reading that it's really much faster".
This is inefficient and wasteful of time, clearly. However, if you just sit down and code, and you don't really know what the hell you are supposed to be coding (in this case, the features, performance and reliability requirements needed by this large financial institution were immense - it's just that the President didn't really know about the details and wasn't appropriate to be in on anything beyond the initial project launch meeting, but he refused to delegate to the CIO and domain experts at the company).
A lot of it is that certain projects, for political rather than technical reasons get set up to fail. Often times, the more important a project is to a company, the more likely it is going to replace other systems built by other people, or displace current employees responsibilities, the more likely there is a political incentive for somebody to pull some strings to get some input so they can throw in some unimplementable requirements into the process. Other times, the executives sponsoring a project just don't know that the people in accounting really shouldn't have any feedback on this system, so they insist on the meeting anyway. Mostly, it's about having well defined goals and a well-scoped project so the project leadership can effectively push back against this kind of shit.
Sorry, I did read the intro and conclusion of your report, I admit I didn't read the entirety of it however. I just scanned through the rest, and I see you note their revenues and profitability, but you don't carry it the extra step and look at their comparables, and price-to-earnings/revenue/EBITDA whatever ratios prior to and after the lawsuit, and back out the anticipated revenue stream the market has factored into the 17x markup in the price. That's the kind of thing I was mentioning that I thought would be interesting to see.
Don't get me wrong, I wasn't dissing your report, which I think is otherwise very good for a college business class analysis!
That's not a very interesting question to ask. The interesting question to ask is what is their value based on actual fundamentals, and look at the length of time the case drags on as a variable in market perception of their value. Realistically, they aren't going to win, and if they do "win", it will be a very limited sort of victory with fairly limited upside - since as soon as discovery is done with, any actual infringing code will be rapidly excised from the Linux kernel with much prejudice. Whether damages would be awarded or not remains to be seen, but the amount that SCO has bet on this lawsuit is such that their only profitable exit strategy is a sale or surreptitious side deal with a major player (Microsoft for example) - realistic court awards for the likely end results will never really cover the millions of dollars bet on this case in actual cash terms plus shareholder dilution from stock payola to Boies et. al.
Nope, the value of this suit is in inflated stock prices and PR/"goodwill" (jeez, how can it be called goodwill with anybody but the investors who've profited big time from this fiasco - maybe we can introduce a new term for intrinsic value of marketplace notoriety).
Guess what, those companies can suck my everloving COCK. They stick software surreptitiously on my computer and try to put deceptive wording in their EULAs (which they know nobody can possibly read in full detail for every product they install) and don't prompt during the install process - they can TRY to take me to court, and they'll find my legal cock so far down their throats they'll need a gastroenterologist to extract it.
Right (and IANAL). I believe in order to make a claim of estoppel, you need to show that you made a reasonable reliance on a promise or contract in entering into other contracts or arrangements, and that the first party reneging on their contract would cause harm or damage to you.
So this should be an affirmative defense against violating their copyright on these portions of the code that they intentionally placed under the GPL, assuming that the corporate entity SCO knowingly did so, the agent had proper authority (it would be hard to argue he didn't, since they had some of these specific claims in their marketing literature and under United Linux joint press releases and so on). Nonetheless, as with any legal argument, there are no guarantees or magic bullets in court. You still have to go pitch that the GPL was a legimitate contract that was entered into by SCO and the recipients/licensees.
Now it starts to seem more clear why SCO's attorneys want to attack the GPL itself. If the contract is illegitimate for other reasons, it seems like it could weaken an estoppel defense. Furthermore, to actually invoke promissory estoppel, I think you need to show that there is a lack of mutual assent as to the contract or the terms thereof. Since there's really no acknowledgement at all of what code may or may not have been "lifted" or where the infringement occurs, it's not yet possible to invoke estoppel until the discovery phase airs all this stuff out publically (which may never even happen).
I have to stand up for Cringely somewhat on this one. The cmd comment is dumb, admittedly, and from an economic and business standpoint, clearly MS would never want to do something like this. Nonetheless, the Win32 API could be ported to run on top of Linux/X. What exactly do you think WINE is, if not 80% of such a beast. And if Microsoft made it themselves, it would actually work well, rather than just working sometimes like WINE.
Another way of looking at it is that he's saying that somebody could create a lot of value on top of the existing Linux platform by making a decent GUI/Windowing System, the same way that Apple did with OS X, and still have a viable commercial product out of it, one which would be better than Windows in many ways, which I agree with as well. Again, clearly makes no sense from a business perspective, but the idea isn't as totally without merit as you make it seem.
Seems like a lot of work to make a fake just to auction it off for a target price of 4-6 grand. I mean, faking a 50-100 thousand dollar painting, I can see. But this? Waste of time.
Pretty sad outlook. What the hell is the evolutionary point of existence without being able to father children, and yes, blow some of your wealth on them? No, no, you took away the wrong lesson from this story. The *RIGHT* lesson is to always, and I mean ALWAYS, get a prenuptial agreement, even if you don't think you have enough money to merit it. Learn from the wealthy elite, you'll notice that they always follow this rule (or they get raked over the coals, and end up not among the wealthy elite).
Anyway, it's never really child support per se that does you in financially - I mean, you had the kid in the first place, presumably that meant you decided you could afford the basic necessities of child care, schooling, etc., and guys who get divorced and try to get out of raising their kids fucking disgust me - that's about as low as it gets, and I've seen some DIRTY FILTHY rich fucks try to get out of caring for their children. It's the alimony and the crazy allocation of wealth that goes on in some divorces that costs you, and can be very unfair.
You can take my advice or leave it, but no matter how sweet a woman may seem, remember that things may change, people get bitter, and when that happens, they are out for themselves. It's like that tattoo that says "I love Lola" that seemed like a good idea at the time, but costs you dearly to have lasered out 5 years later. Even if it doesn't seem romantic, if you got as far as the proposal part, you need to be mature enough to discuss it and get something drafted up by a lawyer. And remember, if all she wants is half of your net worth in the event of a divorce, maybe you should step back and consult with your friends and family again before you jump into this.
"Fix it". Okay, many of us have been trying to fix the fact that it's illegal to fix it for some time now. The problem here is a legislative problem, not a technical problem. Thus it's everybody's problem - even outside of the US, DMCA-like legislation has started taking over. Your attitude - "it's not my problem, you fix it" is the kind of apathy that has allowed special interests to push through monopoly-enforcing legislation like the DMCA and then bitch about it like it's Red Hat's fault, or whatever distro can't bundle in proper DVD support for fear of lawsuit.
There are lots of technical and usability issues in various Linux distributions that lots of people have put lots of time into fixing, and will continue to. But the legal problems require every voters support to solve - don't vote for shitheads who buckle to special interest and "support strong copyright legislation" instead of protecting consumer's rights (AKA citizen's rights).
Most of these problems are economic outgrowths of the fact that most Open Source developers write code for kudos, not bucks. The only way to change this would be to change the incentive system, roll in more capitalism to the process, or come up with ways other than dollars to align large numbers of developers interests in the same direction. Frankly, I'm doubtful about the prospect - the beautiful thing about Open Source is that there will always be more projects as there are more itches to scratch and people will always fight and bicker about which is best. I think the general public will become more aware of this over time and more understanding that this process generally creates good, useful software, and I think the community of Open Source developers has become and will continue to become more aware that adoption of their products depends on being considerate of UI design and usability issues from the outset, not just throwing them on as afterthoughts. More and more Open Source projects seem to be producing fairly usable software these days, not just software that works well if you can navigate a million command-line options like we saw a lot a couple of years back.
As for the big complaint about the Microsoft shoulder-chip, I agree. Anti-Windows fanaticism is just unpleasant to hear. The point the author makes is valid - many users don't have any love for Windows either, but don't have the level of dedication to hating Microsoft that they are willing to spend hours, weeks or months futzing with their hardware and peripherals getting them to work in Linux, or learning new applications. Developers should redouble their efforts and their committment to making ease-of-use, hardware compatibility, short learning curves, and usable GUIs key elements of major Open Source projects.
Uh, maybe the video was hosted elsewhere before it was up at that domain? You honestly think it was just chance that these things all happened about the same time? Let's see, what scenario is more likely:
1) that the iPod product management team had an emergency meeting when somebody first forwarded this video to them, leading to a rapid change in the battery replacement policy. Rapid Apple fans are angry because video creators don't immediately remove any possibly besmirching references to their beloved company, Apple.
2) Two wily brothers in New York happen to record Apple's customer support line or craft an entire fictitious story _after_ hearing about Apple's new $99 battery replacement plan, hoping to besmirch Apple's precious reputation and anger rapid, mouth-foaming fans.
I think the first scenario is a bit more plausible.
No, the video is not bullshit. Apple instituted the 99 dollar battery replacement policy in _response_ to the video. Go read the links above in this thread, where the full story is explained. The problem is Mac fanatics who write stuff like this trying to discredit these two guys, who made an amusing video out of their frustration with Apple tech support - and it was very effective at getting Apple's attention, and resolving the issue.
They are harder to support - not necessarily harder to make, since it's easier to hire people familiar with standard Windows APIs than to hire console developers. But I wasn't trying to explain the entire market and price points, just give an inkling of what might be justifying pricing.
Economics 101 tells us there is a demand curve - consumers will demand more at a lower price. The real question is whether there is a breakout price point at which the market grows sufficiently that the amount of money made per game (and for the industry as a whole) is substantially more because a broader market of consumers is willing to purchase more games at that price point. If so, why not try playing at that price point?
I am not inside the heads of the big console companies - but I know that they don't make money off of their consoles, they make money off of licensing fees on games. Incidentally, this is "the reason" console games are more expensive - there's a chunk of money that goes to license fees and the like to the console manufacturer (I don't know what these deals generally look like, so I don't know exactly what their slice is - and again, I recognize that pricing is actually a complicated interplay between competition, supply, demand and manufacturing/development costs).
Incidentally, I would assume that the console companies do some market research, focus groups, and so on to fine tune target prices for console systems and games. However, you're probably right, they run those groups with hardcore gamers, assuming that is their target market, rather than spending a lot of effort trying to figure out how to interest the broader market in console gaming systems. Such a broad sweeping chage would be a very high risk "betting the business" kind of move, which would be hard to get a large well-established company to make.
I realize you are an obvious troll, since you are arguing against points I never made and things I never said, but I feel compelled to reply to a couple of points. Market for movies vs. the market for PC games. Console game market is ~10 billion, PC game market is ~6 billion (those figures are US market size figures, I believe). Film industry global revenues are about 200 billion dollars (box office revenues about 25 billion alone). There is still about an order of magnitude difference here, though the game industry has been growing a lot faster, and is still pretty huge.
I never said anything about most game companies writing their own 3D engines - I am aware of the economic realities of the industry - precisely the fact that for 3-5 million dollars you really CAN'T develop your own from scratch (duh), thus the reason that most companies don't, or distribute the cost over several to many titles. Did I ever say that most or every game company develops a 3D engine as part of every game they develop? Nope, just that it's hard to write 3D graphics code that works on all PCs. Thus, you are making a straw man argument.
As you mention, everybody gets their start developing for PC because no new game development shop can afford the fees to develop for console. And most of them then want to move on to develop for console. For precisely the reasons I mentioned - if you can afford to be there and can stomach making mass market shit, the margins are usually better. Again, a straw man - I never said that anybody jumps into developing console games, it's generally not possible. But you clearly agree with me that the PC game market is more competitive, and thus generally tends to be lower margin - your citing a couple of ultra-hit titles like Starcraft is pretty much irrelevant to the general economics of PC games.
Also, in the future, paragraphs are your friend, use them. And you might want to think about the person on the other end of the keyboard and realize that they might be a lot smarter than you are before you adopt an imperious, lecturing tone and start throwing the insults out there.
I realize the cost issues associated with console development. You took my sentence entirely out of context - I was saying development shops with the budget and experience want to develop console games because the margins are better, and you don't deal with awful support issues. I realize that it's much more expensive to develop console games, and I think that was explicitly stated, or at least implicit in the rest of my post. Also, 2D games don't seem to be too popular these days in most genres.
Of course eye candy alone doesn't sell games, it's just part of the package, providing visual realism that makes a game more engaging. I never said "Eye candy is the key element that sells games", I said "you need the eye candy to sell the game" (in today's market, where you're up against a lot of compelling, realistic looking games). As for your point about writing your own 3D engine, that's exactly my point. The economics of the industry have made it more sensible to take a low-risk approach to game development - license a 3D engine, license a physics engine, create content, story and special sauce. This is nice, but it tends to kill some of the variety out there. No, every game doesn't need it's own 3D engine, but I think too much homogeneity really sucks.
Anyway, I'm not quite sure what you're trying to prove, since I obviously agree you can make a game on the cheap, or just reduce development time/cost risk by licensing components. My rants were really about my own personal frustration with writing 3D graphics code.
As for the testing angle, yes, what you describe is quite similar to the approach I've used for a small 3D graphics app. I don't know how well that would scale to a large, complex game, but I'm sure it's not impossible to use a similar approach. I was just trying to explain the complexity of dealing with hardware compatibility issues when 3D graphics are involved - people who've never written 3D graphics code don't really appreciate the issue.
Excuse me? I know the DirectX 8 Graphics API quite well. Everything I stated about the DirectX 8 Graphics API is quite true - it is a nice API in that it exposes a lot of features, and provides a unified front for them, unlike OpenGL. It is an annoying and frustrating API in that differences in hardware behavior for certain advanced API features can be frustrating to deal with, and the API documentation with respect to capabilities required for certain API calls is very poor - compared to the kind of professional API documentation I have come to expect in other areas of the software world for a fundamental infrastructure layer API.
For example, I want to do cubic environment mapping with dynamically rendered texture maps for the cube map faces. What specific capabilities does the graphics card need? D3DCAPS2_DYNAMICTEXTURES? Or just D3DPTEXTURECAPS_CUBEMAP? Or maybe you can work with D3DPTEXTURECAPS_CUBEMAP_POW2? It's easy to get it working on *most* hardware, but what about the weird cases?
If you think I don't know jack shit, clearly you have no meaningful experience with Direct3D/DX Graphics.
Sorry, you don't know what you are talking about. Writing real-time 3D apps is nothing like writing other kinds of desktop software. The number of hardware dependencies involved in Direct3D is absurd. OpenGL will work everywhere, until you start using extensions. Basically, you need the eye candy to sell the game, but the eye candy support in the API layer is shitty and nonstandard. It's tough, so you try to make tradeoffs that will let you sell well to the high end gamer market without losing too much of the casual gamer market, and deal with undiscovered hardware dependencies though patches.
I wouldn't believe it either unless I had recently written a DirectX 8 3D app and seen how insanely hardware dependent it all is - the API is supposed to handle hardware abstraction to some degree, but at best it lets you detect capaibilities - at worst, drivers misreport their capabilities, or the API doesn't properly document dependency of certain API functions on various capabilities (in fact, dependencies aren't documented at all in the DX API docs). Give me a nice standardized console any day or a plain jane Win32 app as shitty as that is. If you are doing a big budget 3D game you can afford a horde of testers with a sufficiently broad variety of test hardware to detect _most_ of the major issues up front, but this requires a substantial budget.
That's absurd. The market for movies is huge, compared to the market for PC games. Game development shops, for the most part, run small, low margin businesses. Your calculation is absurd, because the game that sells a million copies returns about 2 million to the developer, 3-4 million to the publisher, 3 million to retailers, and the rest to assorted other folks. In short, you just released a huge new game, got a publishing deal, worked for 2 years developing it, it was a pretty big success, sold a million copies, and you lost a million dollars on the deal.
As for whether publishers and distributers take a bigger cut in the gaming business than the movie business, that's a toughie - I don't know enough to say for sure. But a successful movie might take in 50-100 million dollars so there is more to go around. However, retail chains get much more favorable terms for PC games than for DVD movies, simply because return rates and compatibility issues are massive. Publishers have to deal with support issues, which are also massive.
Try writing a 3D game, which has to run on EVERYBODY'S PC and compare to doing some animations in Maya, which just have to look good from one angle and get rendered once. Not dissing on the Matrix or other heavy-FX movies, but it's really a hell of a lot of work to support and distribute a modern 3D PC game.
This, of course, is why nobody really wants to develop for the flooded PC market and why the console market exists, if you are well capitalized and can afford to hire the right people, get all the SDKs and negotiate good terms.
Slashdot Mirror
Have you tried OpenOffice on Win2k/XP? I tried it and recall it was pretty decently speedy - mind you this was a while ago, so my memory would be faulty. These days I use Office XP, despite the feel-bad MS factor, since I have lots of document exchange to do with Windows users, and I don't want my files to be imported "almost right".
WinMX is good for music/video content. Emule is good for anything else, if a bit slow.
That's how it's supposed to be. The problem is that in practice, I've seen cases where the "emulation" of a vertex shader in CPU didn't work properly (a DX8 vertex shader that ran fine on GPU, but had weird problems on CPU). The solution was a line-for-line port to C++ of the vertex shader, and having a separate execution path for non-VS supporting cards. In short, a big pain in the ass to program for.
You may be right, but if LinuxGazette existed and pre-dated SSC's involvement in the project, how do they have a right to the trademark? This is the problem with these kinds of informal relationships. My guess is that SSC does rightfully own LinuxGazette.com (the domain) because they registered and owned it and provided hosting on behalf of the LinuxGazette publication which they helped sponsor and were involved with for several years. But they can't assert ownership of the trademark over the people who started the publication without evidence of contractual transfer of ownership of the rights to trademarks beyond their registration of a domain name in 1997, period.
Unfortunately, people don't seem to understand the real problem here. The problem is that people make offsetting trades in other markets, that are built on other systems, to lock in profits in the primary market. This story was about traders who sold options contracts to lock in profits on the stock itself. The trades on the stocks were busted by NASDAQ, but the options trades can't be backed out of, they are in a separate market. Thus the trader gets fucked. Having a transactional rollback capability on the NASDAQ wouldn't help here, it would have to encompass all the other markets people might trade in.
Mind you, I would think there would be legal recourse here based on contract law. The buyer entered into an option sale contract with reasonable reliance on the NASDAQ's "promise" that they bought the stock at a low price. Promissory estoppel against the NASDAQ, or against Archipelago? I don't know, sounds to me like an interexchange issue that needs legal or regulatory collaboration more than it needs a technical solution.
But you're generally correct, in a distributed financial marketplace where trades happen in many places and there is no central orderbook or matching system, it's impossible to coordinate large scale transactions via 2PC or any other distributed transaction model.
This is inefficient and wasteful of time, clearly. However, if you just sit down and code, and you don't really know what the hell you are supposed to be coding (in this case, the features, performance and reliability requirements needed by this large financial institution were immense - it's just that the President didn't really know about the details and wasn't appropriate to be in on anything beyond the initial project launch meeting, but he refused to delegate to the CIO and domain experts at the company).
A lot of it is that certain projects, for political rather than technical reasons get set up to fail. Often times, the more important a project is to a company, the more likely it is going to replace other systems built by other people, or displace current employees responsibilities, the more likely there is a political incentive for somebody to pull some strings to get some input so they can throw in some unimplementable requirements into the process. Other times, the executives sponsoring a project just don't know that the people in accounting really shouldn't have any feedback on this system, so they insist on the meeting anyway. Mostly, it's about having well defined goals and a well-scoped project so the project leadership can effectively push back against this kind of shit.
Don't get me wrong, I wasn't dissing your report, which I think is otherwise very good for a college business class analysis!
Nope, the value of this suit is in inflated stock prices and PR/"goodwill" (jeez, how can it be called goodwill with anybody but the investors who've profited big time from this fiasco - maybe we can introduce a new term for intrinsic value of marketplace notoriety).
Guess what, those companies can suck my everloving COCK. They stick software surreptitiously on my computer and try to put deceptive wording in their EULAs (which they know nobody can possibly read in full detail for every product they install) and don't prompt during the install process - they can TRY to take me to court, and they'll find my legal cock so far down their throats they'll need a gastroenterologist to extract it.
So this should be an affirmative defense against violating their copyright on these portions of the code that they intentionally placed under the GPL, assuming that the corporate entity SCO knowingly did so, the agent had proper authority (it would be hard to argue he didn't, since they had some of these specific claims in their marketing literature and under United Linux joint press releases and so on). Nonetheless, as with any legal argument, there are no guarantees or magic bullets in court. You still have to go pitch that the GPL was a legimitate contract that was entered into by SCO and the recipients/licensees.
Now it starts to seem more clear why SCO's attorneys want to attack the GPL itself. If the contract is illegitimate for other reasons, it seems like it could weaken an estoppel defense. Furthermore, to actually invoke promissory estoppel, I think you need to show that there is a lack of mutual assent as to the contract or the terms thereof. Since there's really no acknowledgement at all of what code may or may not have been "lifted" or where the infringement occurs, it's not yet possible to invoke estoppel until the discovery phase airs all this stuff out publically (which may never even happen).
Another way of looking at it is that he's saying that somebody could create a lot of value on top of the existing Linux platform by making a decent GUI/Windowing System, the same way that Apple did with OS X, and still have a viable commercial product out of it, one which would be better than Windows in many ways, which I agree with as well. Again, clearly makes no sense from a business perspective, but the idea isn't as totally without merit as you make it seem.
Seems like a lot of work to make a fake just to auction it off for a target price of 4-6 grand. I mean, faking a 50-100 thousand dollar painting, I can see. But this? Waste of time.
Anyway, it's never really child support per se that does you in financially - I mean, you had the kid in the first place, presumably that meant you decided you could afford the basic necessities of child care, schooling, etc., and guys who get divorced and try to get out of raising their kids fucking disgust me - that's about as low as it gets, and I've seen some DIRTY FILTHY rich fucks try to get out of caring for their children. It's the alimony and the crazy allocation of wealth that goes on in some divorces that costs you, and can be very unfair.
You can take my advice or leave it, but no matter how sweet a woman may seem, remember that things may change, people get bitter, and when that happens, they are out for themselves. It's like that tattoo that says "I love Lola" that seemed like a good idea at the time, but costs you dearly to have lasered out 5 years later. Even if it doesn't seem romantic, if you got as far as the proposal part, you need to be mature enough to discuss it and get something drafted up by a lawyer. And remember, if all she wants is half of your net worth in the event of a divorce, maybe you should step back and consult with your friends and family again before you jump into this.
There are lots of technical and usability issues in various Linux distributions that lots of people have put lots of time into fixing, and will continue to. But the legal problems require every voters support to solve - don't vote for shitheads who buckle to special interest and "support strong copyright legislation" instead of protecting consumer's rights (AKA citizen's rights).
As for the big complaint about the Microsoft shoulder-chip, I agree. Anti-Windows fanaticism is just unpleasant to hear. The point the author makes is valid - many users don't have any love for Windows either, but don't have the level of dedication to hating Microsoft that they are willing to spend hours, weeks or months futzing with their hardware and peripherals getting them to work in Linux, or learning new applications. Developers should redouble their efforts and their committment to making ease-of-use, hardware compatibility, short learning curves, and usable GUIs key elements of major Open Source projects.
1) that the iPod product management team had an emergency meeting when somebody first forwarded this video to them, leading to a rapid change in the battery replacement policy. Rapid Apple fans are angry because video creators don't immediately remove any possibly besmirching references to their beloved company, Apple.
2) Two wily brothers in New York happen to record Apple's customer support line or craft an entire fictitious story _after_ hearing about Apple's new $99 battery replacement plan, hoping to besmirch Apple's precious reputation and anger rapid, mouth-foaming fans.
I think the first scenario is a bit more plausible.
No, the video is not bullshit. Apple instituted the 99 dollar battery replacement policy in _response_ to the video. Go read the links above in this thread, where the full story is explained. The problem is Mac fanatics who write stuff like this trying to discredit these two guys, who made an amusing video out of their frustration with Apple tech support - and it was very effective at getting Apple's attention, and resolving the issue.
Economics 101 tells us there is a demand curve - consumers will demand more at a lower price. The real question is whether there is a breakout price point at which the market grows sufficiently that the amount of money made per game (and for the industry as a whole) is substantially more because a broader market of consumers is willing to purchase more games at that price point. If so, why not try playing at that price point?
I am not inside the heads of the big console companies - but I know that they don't make money off of their consoles, they make money off of licensing fees on games. Incidentally, this is "the reason" console games are more expensive - there's a chunk of money that goes to license fees and the like to the console manufacturer (I don't know what these deals generally look like, so I don't know exactly what their slice is - and again, I recognize that pricing is actually a complicated interplay between competition, supply, demand and manufacturing/development costs).
Incidentally, I would assume that the console companies do some market research, focus groups, and so on to fine tune target prices for console systems and games. However, you're probably right, they run those groups with hardcore gamers, assuming that is their target market, rather than spending a lot of effort trying to figure out how to interest the broader market in console gaming systems. Such a broad sweeping chage would be a very high risk "betting the business" kind of move, which would be hard to get a large well-established company to make.
I never said anything about most game companies writing their own 3D engines - I am aware of the economic realities of the industry - precisely the fact that for 3-5 million dollars you really CAN'T develop your own from scratch (duh), thus the reason that most companies don't, or distribute the cost over several to many titles. Did I ever say that most or every game company develops a 3D engine as part of every game they develop? Nope, just that it's hard to write 3D graphics code that works on all PCs. Thus, you are making a straw man argument.
As you mention, everybody gets their start developing for PC because no new game development shop can afford the fees to develop for console. And most of them then want to move on to develop for console. For precisely the reasons I mentioned - if you can afford to be there and can stomach making mass market shit, the margins are usually better. Again, a straw man - I never said that anybody jumps into developing console games, it's generally not possible. But you clearly agree with me that the PC game market is more competitive, and thus generally tends to be lower margin - your citing a couple of ultra-hit titles like Starcraft is pretty much irrelevant to the general economics of PC games.
Also, in the future, paragraphs are your friend, use them. And you might want to think about the person on the other end of the keyboard and realize that they might be a lot smarter than you are before you adopt an imperious, lecturing tone and start throwing the insults out there.
Thank you, I have now bitten on the trollbait.
I realize the cost issues associated with console development. You took my sentence entirely out of context - I was saying development shops with the budget and experience want to develop console games because the margins are better, and you don't deal with awful support issues. I realize that it's much more expensive to develop console games, and I think that was explicitly stated, or at least implicit in the rest of my post. Also, 2D games don't seem to be too popular these days in most genres.
Anyway, I'm not quite sure what you're trying to prove, since I obviously agree you can make a game on the cheap, or just reduce development time/cost risk by licensing components. My rants were really about my own personal frustration with writing 3D graphics code.
As for the testing angle, yes, what you describe is quite similar to the approach I've used for a small 3D graphics app. I don't know how well that would scale to a large, complex game, but I'm sure it's not impossible to use a similar approach. I was just trying to explain the complexity of dealing with hardware compatibility issues when 3D graphics are involved - people who've never written 3D graphics code don't really appreciate the issue.
For example, I want to do cubic environment mapping with dynamically rendered texture maps for the cube map faces. What specific capabilities does the graphics card need?
D3DCAPS2_DYNAMICTEXTURES? Or just D3DPTEXTURECAPS_CUBEMAP? Or maybe you can work with D3DPTEXTURECAPS_CUBEMAP_POW2? It's easy to get it working on *most* hardware, but what about the weird cases?
If you think I don't know jack shit, clearly you have no meaningful experience with Direct3D/DX Graphics.
I wouldn't believe it either unless I had recently written a DirectX 8 3D app and seen how insanely hardware dependent it all is - the API is supposed to handle hardware abstraction to some degree, but at best it lets you detect capaibilities - at worst, drivers misreport their capabilities, or the API doesn't properly document dependency of certain API functions on various capabilities (in fact, dependencies aren't documented at all in the DX API docs). Give me a nice standardized console any day or a plain jane Win32 app as shitty as that is. If you are doing a big budget 3D game you can afford a horde of testers with a sufficiently broad variety of test hardware to detect _most_ of the major issues up front, but this requires a substantial budget.
As for whether publishers and distributers take a bigger cut in the gaming business than the movie business, that's a toughie - I don't know enough to say for sure. But a successful movie might take in 50-100 million dollars so there is more to go around. However, retail chains get much more favorable terms for PC games than for DVD movies, simply because return rates and compatibility issues are massive. Publishers have to deal with support issues, which are also massive.
Try writing a 3D game, which has to run on EVERYBODY'S PC and compare to doing some animations in Maya, which just have to look good from one angle and get rendered once. Not dissing on the Matrix or other heavy-FX movies, but it's really a hell of a lot of work to support and distribute a modern 3D PC game.
This, of course, is why nobody really wants to develop for the flooded PC market and why the console market exists, if you are well capitalized and can afford to hire the right people, get all the SDKs and negotiate good terms.