may have a poor launch because the quality of the first titles won't be much better than the games we have now on the latest generation of consoles
What launch titles?
That's the thing with the 360. I keep looking for a reason to want to go get a pre-order in, or to be excited for the first console launch in a long time, but... What am I going to play on it? DVDs?
I'm sure the reason they haven't announced the list yet is because developers are still trying to figure out if they can deal with the sudden lack of hard drive in time for the launch, but how can they expect people to be drooling over this thing if it's just a $400 hunk of plastic that sits idle on top of your TV?
As for holiday sales... Parents don't buy these things if the kids don't ask, and kids don't care about specs, they care about games. A TV ad with a shiny white box isn't going to get the kids to nag their parents.
I'm comfortable in my correctness, even if I can't convince all of you.
Enough people... Hell, enough companies agree with me that "reference implementations" for tons of technologies exist. That is, code that you can use to learn exactly how something works, even if you wouldn't necessecarily want to run it as written.
Being right in real life is way better than being right on Slashdot.
Personally, if I could, I'd have an ISP that did nothing but route IP packets for me. I don't want to pay for "value added features" like crappy e-mail service, crappy web space, access to a crappy news server, and a crappy "firewall."
Besides, the whole point of this box is so your ISP can collect the fee, not so it would pay one. The ISP would buy the box, and you would "rent" it from them. (I say that in quotes because you'd probably buy it, and then pay a service fee on top of that.)
Huh? There are dozens of ways to implement parsers and grammars given a defined language. The Gecko engine is but one approach to solving HTML parsing and rendering, and not necessarily the best or most efficient approach.
So because you used code as an example, suddenly all implementations need to use the same method? Why? The code can tell you what tags are allowed where in a way that is difficult to match with plain old text. That's the important part. The rest of that crap is you pulling irrelevant stuff like "best" and "efficient" into it.
We've ventured into the obscene with this example anyway, because rendering got pulled into it, and there's nothing in the HTML specs about rendering in any specific way.
Plus we've gotten so far away from my original point that I don't even know why I'm arguing this anymore. Original point: Specs (the ones for public consumption anyway) are for communicating technical details in a way that is sufficiently vague as not compromise the implementers' and authors' intellectual property; The more specific you can be the better; Nothing is more specific than a clearly written implementation.
You are wrong. You cannot reverse-engineer a spec from an implementation, because you cannot separate the implementation choices from spec requirements
Requirements are not specs. Specs are not requirements.
Similarly, there are almost always things in a spec that a particular implementation does not need (but another implementation would). To piece back together the actual spec would require reading multiple implementations and figuring out the union of all they implement. Worse, the implementations may actually contradict each other.
Rethink this imagining that reference code were written not to be used, but to be read. Reviewed and assembled by committee as a spec, and not for a particular application. Think of it more as a spec that isn't allowed to be ambiguous in any harmful manner.
The reason this isn't done is because it leaves little room to build compliant proprietary intellectual property, not because it's harder to read than a PDF file full of abreviations, assumptions, and bad grammar.
So the complete source code to Mozilla is a better source of information on HTML than the W3C HTML specification?
Well, let's pretend you said Gecko, and not Mozilla, and that Gecko was both written clearly in a peer-reviewed environment, and 100% compliant. That way we'll be comparing apples to apples.
The answer would then become "It depends". If your goal was to implement an unambiguous parser than yes. If your goal was to learn how to write HTML documents, I'd say no, but only because both would be equally terrible sources of knowledge for that purpose.
That's rediculous. I put maintenence fees into my car for finite, well defined purposes. I don't spend some fixed amount just in case. Anybody who charged me in such a way would be silly to do it without charging enough to ensure a huge profit margin.
Yes I incur expenses, but I know what they're for and can decide if I want to spend the money or not. I didn't give somebody the keys to my bank account without any guarantee that they'll do actual work, or that I'll approve of what they're doing.
Do you pay a monthly fee for your car to keep working?
Nope. I only do work on it (and pay the associated costs) when it needs it... Not every month for the hell of it, and certainly not without knowing exactly what they're going to do first.
The problem comes because vendors simply won't follow the spec if that might hurt revenue
Hurt revenue? Please. Since we're using SCSI as an example... The problem is that people won't follow the spec because it doesn't fit the model set by their crufty OS code written decades before the spec, so they do their own thing that is almost compliant, but generates all sorts of caveats that other vendors will be forced to blindly interoperate with. That's why most storage arrays have different modes for what OS the host is running... It has to know which pseudo-SCSI to speak depending on if you're running Windows, HP/UX, Solaris, AIX, or whatever. Remember, SCSI is only an example here. This becomes true in almost any multi-platform or multi-vendor environment. Devices that don't differentiate will only work in the most basic of operations.
Sure, there aren't enough specifics to be helpful in whatever area of innovation is driving revenue right now, but all the old boring settled stuff stays settled, which reduces the driver-writing nightmare by an prder of magnitude.
You've never coded for SCSI, have you?
The spec represents some ideal magical world where everything plays nice, and makes sense... Or at least is really vaguely defined. Reality is that every vendor's device does things like error recovery, status, timing, addressing, and availability in a unique way that isn't documented anywhere. The SCSI spec doesn't represent the past, it represents idealism and old flame wars combined with enough of real life to make you almost think you understand it. It increases the driver-writing nightmare (especially the target mode side) by an order of magnitude since all the things that the big vendors took liberties with and implemented differently from each other remain undefined.
You would have an easier time learning the SCSI protocol with an analyzer and a few hundered devices (that all speak SCSI differently) than you would by reading the spec. In fact, unless you're doing the most basic of block device operations, I'd say it is impossible to write a fully working SCSI implementation (target or initiator) from the spec alone.
Hardly useless.
Who said useless? The problem is that we can't live without it because we don't have something better around that would make it useless.
The PIC is a complete solution, supported through a local service provider
Look! It's got recurring revenue generation built in! Not only can you pay for it up front, but you can keep paying for it month after month; forever! ALl the while you'll be giving control of it over to your favorite ISP, who can reduce it's functionality at their whim, or upon lawsuit, whichever comes first.
I'm under the impression that this type of argument is usually refered to as the "straw man." You redefine the issue ("there is only one reason for having specs and it is this") to something that you can refute, refute it, and then declare victory.
I'd have to be wrong about the purpose of specs for this to be the case.
So are we saying whoever gets there first wins? I.e. if you are the first to define a protocol in code, everyone else must follow what you've said?
Hell, no. Why wouldn't the code go through the draft/revision process like a spec? Or like open source software tends to go through already?
Admitedly, my point is moot when it comes to closed/commercial applications.
Or perhaps we might call upon the invisible hand of the market to decide. Saying everyone code their solution to the problem... and whatever is used becomes the de facto standard. But doesn't this imply that a lot of people will spend a lot of time creating code that will never be used? Is this really the most efficient process?
What were you saying about straw-man arguments?
That the goal of development can be agreed upon before any development starts so that more than one solution can be available at the same time.
Defining requirements is not the job of a spec. A spec sets out the technical details required for use or interoperability. A requirements document has a much smaller scope. Generally the requirements end up being merely the introduction to a spec, if not a completely seperate document.
In fact for closed-source code I think this is as strong a reason as the one you posit.
No matter how dysfunctional the process generally becomes, I would not argue that specs are useless in a closed source environment. I didn't think that was what we were talking about though.
Who needs to consum it when you can just copy the code? Really, if you want something low impact, write a requirements document and leave the technical details up to the implementor. If your spec is specific enough to allow the consumer to anticipate every concievable situation, it will be just as complex as the code. If your spec isn't specific enough to allow the consumer to anticipate every concievable situation, then you will have incompatabilities, or tons of pre-required knowledge.
POSIX, like most specs, is designed to allow software to be both closed-source, and compatible. When your code is available, the sole traditional reason for specs is gone.
Specs that are written by a group of competing organizations are worse than obsolete. They're disaterous. A lengthy revision process slowly, but completely removes all but the most necessary of the specifics from the document in order to match as closely as possible the existing technology from all parties involved. This leads to standards compliant compatibility nightmares. Look at SCSI for a perfect example of this.
Code examples are always better than specs because they are unambiguous. Better yet if the code is commented when the reasoning is unclear. Code combined with a spec can't hurt if the code is the ultimate authority, but what's the point?
It hardly makes things better at all if you leave out all the rest of the benefits when you quote my comment, but it's still a benefit. Mining uranium is easy, technologically speaking, when compared to drilling under the surface of the ocean. Plus you need far less material to extract the same amount of energy. Also, It sometimes exists in places we were mining anyway for things like coal.
Anyway, you don't drill for it. Generally you use explosives and large trucks.
The problem that won't go away in 2007 is the winter demand for heating oil, which cuts into the diesel supply, since they're refined from similar weight crude content. Further natural gas development would help, but too many people are paranoid about it.
You know what else would help? Nuclear power. If nuclear power were abundant, we could heat our houses without any fossil fuels or carbon emissions at all. We wouldn't need to drill for natural gas, and our oil consumption would be signifigantly reduced.
Don't forget that basically every present console is selling at a loss and I am pretty sure they have been from day one.
I'd love for you to show proof, but you can't because there is none.
Word is that the PS2 hardware is profitable now, and was within a year, and that the GameCube was profitable on day 1. Microsoft, however, has not only lost money on the hardware for Xbox, but they haven't come close to making it back on game royalties. They've lost billions. I'm fairly certain that they won't let that be the case for the 360, or if they do they'll have to answer to their shareholders and respond to anti-dumping lawsuits from Sony and Nintendo.
Even if they are breaking even, their long term pricing flexability is incredibly low, because unlike Sony, Microsoft has to buy all the parts for the 360. That means when manufacturing costs go down there's another player that takes a cut of the cash. Manufacturers that control the entire supply chain, however, get all the benefit and flexability of increased manufacturing efficiency.
Everything I have heard so far seems to point that Microsoft is making a nice profit at the prices listed
It would be surprising if they were doing better than breaking even. Those graphics chips and processors aren't free, you know, and they're buying them from a third party. A third party who *is* turning a profit on the hardware.
And what games do you know of that require the HDD?
None. But that wouldn't really be the kind of thing they'd advertise. We'll have to wait and see on this one. I can think of some that will have trouble without it... Or will at the very least use TONS of memory card. I'm also certain that some of the games that have been announced were designed under the assumption that the hard drive would be in the default configuration. Imagine playing a game like Oblivion with no hard drive. It can't be pretty.
BTW, it will be retailers who will most likely be eating return cost not Microsoft.
That's funny. You do know that Wal-Mart could crush Microsoft like a bug if they wanted to, right? Nearly zero retail profit margin, and they have to eat the loss on returns? Not likely. Not if Microsoft wants Wal-Mart to sell any of these things (And guess where 80%+ of them will be sold...). I bet Wal-Mart doesn't even have to eat the losses when they mark down the games. I'm sure they have deals set up that would turn places like EB green with envy.
Additionally, we're not going to get the chance to play demos for the system until February of 2006.
Actually, the article didn't even come close to saying that. It said:
When asked if there would be any changes to the February PS3 event where playable demos will be on hand, Saeki did not respond directly. However, he did say that SCE is planning something for the event that is sure to be a "major" surprise.
That could mean there will be demos sooner, or that you won't even get demos in February. It doesn't mean what the summary says.
But like the theories go, expect Halo 3 and a price drop just as PS3 is coming out.
If so, expect a Microsoft shareholder revolt shortly afterward...
Xbox was allowed to lose billions of dollars over the console's lifespan to prime the market for version 2. You really think Microsoft can get away with not turning a profit on the 360 too? Why are they in the business then?
If Microsoft had even the least little bit of flexability in the pricing, you wouldn't have seen them fuck themselves by releasing two versions the way they did. I'll be extremely surprised if we see a price drop on the 360 before Christmas 2006, and even then I'd be surprised if it was more than a $50 drop.
As it is, if they don't make every game work flawlessly without the hard drive, they'll be lucky if the thing still exists after this Christmas. Parents are going to buy their kids the cheap one, and every time a game doesn't work right because they didn't get the expensive one, Microsoft is going to have to eat the cost of a return.
Then, a day or two ago both Microsoft and Sony announced support for the competing HD DVD format, and suddenly Sony has real competition in a fight that looked to be a foregone conclusion in their favor.
This crap gets propgated because the trade rags love a format war.
The Microsoft/Intel announcement was meaningless. It didn't sat "exclusive" in there. Windows will support both. The whole story was a cover so they could slip that fact that the release date for HD_DVD devices was getting pushed back again under the radar.
As such, any speculation based on this announcement is bogus.
I think your conclusion about the prices is exactly correct, but the reasoning is suspect.
Uh. The 41% was one guy, and the 59% was 5 guys. This one guy was taking home 41% of the cash while the other people (who probably worked just as hard for it) had to split the remaining 59% five ways... And it seems like they didn't even have a problem with it until he tried to cash out at massive profit for himself and massive profit divided by five for everybody else.
Did he think they'd send him a fruit basket for that?
If you started a company with five other guys, and one of them was taking home $3.5 mil in profits every year, while you only got $300k, what would you be thinking?
1) You mean the forums where the people with problems bitch, but the people who have no trouble don't bother posting in? 2) I meant in general. Of course there are exceptions. 3) Yeah. I use versamail though, and it works just fine with exchange. 4) The IT department just sets it up. The user only needs to know which of the four buttons on the front to push. 5) I have a Treo 650 from the day they came out. You're full of shit. 11) See #1
It's mostly screen and battery. If the iPod nano had to transmit over RF constantly, it would be a lot bigger too.
Palm knows how to make things tiny. Look at the Tungsten T3. I think the only real way they could slim the treo down is if they made the case out of some thin metal.
discovers that they can't do the simple and obvious things that they had come to expect that they could do with it; like backing it up
Would you please stop using this example?
Most people don't make backups. It's a fact of life, and it's well known. That means every time you break out the "backups argument" it's automatically parsed into the piracy argument by practically everybody. From the point you mention backups on, you've lost all credibility with everbody except for the people who already agree with you.
When you're talking about music, talk about using it in your car. Talk about mix CDs. Talk about the iPod... Don't talk about backups!
When you're talking about images or video, talk about watching them in the car. Talk about watching them on your computer. Talk about getting a print made at the local photo shop. Talk about sharing home video made on your camcorder with the family. Don't use the word backups!
Say what you will, practically everybody that used to carry a Blackberry, now carries a Treo. That's a technical success. How Palm has turned that into a losing business is the story.
Except for #4, BTW, everything you listed is either incorrect, or irrelevant. I'll enumerate:
1) Bluetooth works fine on the 650. Especially with the latest software 2) People are upgrading from Blackberrys, not older Treos, so this is irrelevant. 3) Every executive I know with a Treo runs third party e-mail software from Goodlink 4) Bullshit. Besides, company IT departments handle this. 5) What? This is just wrong. (Maybe it's true on Verizon?) 6) How is this different from any other device? 7) Wrong. 8) See #3 9) See #2 10) See #4 11) See #1
Buy what you like, but that won't change the fact that they've sold tons of these things already.
Slashdot Mirror
may have a poor launch because the quality of the first titles won't be much better than the games we have now on the latest generation of consoles
What launch titles?
That's the thing with the 360. I keep looking for a reason to want to go get a pre-order in, or to be excited for the first console launch in a long time, but... What am I going to play on it? DVDs?
I'm sure the reason they haven't announced the list yet is because developers are still trying to figure out if they can deal with the sudden lack of hard drive in time for the launch, but how can they expect people to be drooling over this thing if it's just a $400 hunk of plastic that sits idle on top of your TV?
As for holiday sales... Parents don't buy these things if the kids don't ask, and kids don't care about specs, they care about games. A TV ad with a shiny white box isn't going to get the kids to nag their parents.
I'm comfortable in my correctness, even if I can't convince all of you.
Enough people... Hell, enough companies agree with me that "reference implementations" for tons of technologies exist. That is, code that you can use to learn exactly how something works, even if you wouldn't necessecarily want to run it as written.
Being right in real life is way better than being right on Slashdot.
You don't think that's passed on to you?
Personally, if I could, I'd have an ISP that did nothing but route IP packets for me. I don't want to pay for "value added features" like crappy e-mail service, crappy web space, access to a crappy news server, and a crappy "firewall."
Besides, the whole point of this box is so your ISP can collect the fee, not so it would pay one. The ISP would buy the box, and you would "rent" it from them. (I say that in quotes because you'd probably buy it, and then pay a service fee on top of that.)
Huh? There are dozens of ways to implement parsers and grammars given a defined language. The Gecko engine is but one approach to solving HTML parsing and rendering, and not necessarily the best or most efficient approach.
So because you used code as an example, suddenly all implementations need to use the same method? Why? The code can tell you what tags are allowed where in a way that is difficult to match with plain old text. That's the important part. The rest of that crap is you pulling irrelevant stuff like "best" and "efficient" into it.
We've ventured into the obscene with this example anyway, because rendering got pulled into it, and there's nothing in the HTML specs about rendering in any specific way.
Plus we've gotten so far away from my original point that I don't even know why I'm arguing this anymore. Original point: Specs (the ones for public consumption anyway) are for communicating technical details in a way that is sufficiently vague as not compromise the implementers' and authors' intellectual property; The more specific you can be the better; Nothing is more specific than a clearly written implementation.
You are wrong. You cannot reverse-engineer a spec from an implementation, because you cannot separate the implementation choices from spec requirements
Requirements are not specs. Specs are not requirements.
Similarly, there are almost always things in a spec that a particular implementation does not need (but another implementation would). To piece back together the actual spec would require reading multiple implementations and figuring out the union of all they implement. Worse, the implementations may actually contradict each other.
Rethink this imagining that reference code were written not to be used, but to be read. Reviewed and assembled by committee as a spec, and not for a particular application. Think of it more as a spec that isn't allowed to be ambiguous in any harmful manner.
The reason this isn't done is because it leaves little room to build compliant proprietary intellectual property, not because it's harder to read than a PDF file full of abreviations, assumptions, and bad grammar.
So the complete source code to Mozilla is a better source of information on HTML than the W3C HTML specification?
Well, let's pretend you said Gecko, and not Mozilla, and that Gecko was both written clearly in a peer-reviewed environment, and 100% compliant. That way we'll be comparing apples to apples.
The answer would then become "It depends". If your goal was to implement an unambiguous parser than yes. If your goal was to learn how to write HTML documents, I'd say no, but only because both would be equally terrible sources of knowledge for that purpose.
That's rediculous. I put maintenence fees into my car for finite, well defined purposes. I don't spend some fixed amount just in case. Anybody who charged me in such a way would be silly to do it without charging enough to ensure a huge profit margin.
Yes I incur expenses, but I know what they're for and can decide if I want to spend the money or not. I didn't give somebody the keys to my bank account without any guarantee that they'll do actual work, or that I'll approve of what they're doing.
Do you pay a monthly fee for your car to keep working?
Nope. I only do work on it (and pay the associated costs) when it needs it... Not every month for the hell of it, and certainly not without knowing exactly what they're going to do first.
The problem comes because vendors simply won't follow the spec if that might hurt revenue
Hurt revenue? Please. Since we're using SCSI as an example... The problem is that people won't follow the spec because it doesn't fit the model set by their crufty OS code written decades before the spec, so they do their own thing that is almost compliant, but generates all sorts of caveats that other vendors will be forced to blindly interoperate with. That's why most storage arrays have different modes for what OS the host is running... It has to know which pseudo-SCSI to speak depending on if you're running Windows, HP/UX, Solaris, AIX, or whatever. Remember, SCSI is only an example here. This becomes true in almost any multi-platform or multi-vendor environment. Devices that don't differentiate will only work in the most basic of operations.
Sure, there aren't enough specifics to be helpful in whatever area of innovation is driving revenue right now, but all the old boring settled stuff stays settled, which reduces the driver-writing nightmare by an prder of magnitude.
You've never coded for SCSI, have you?
The spec represents some ideal magical world where everything plays nice, and makes sense... Or at least is really vaguely defined. Reality is that every vendor's device does things like error recovery, status, timing, addressing, and availability in a unique way that isn't documented anywhere. The SCSI spec doesn't represent the past, it represents idealism and old flame wars combined with enough of real life to make you almost think you understand it. It increases the driver-writing nightmare (especially the target mode side) by an order of magnitude since all the things that the big vendors took liberties with and implemented differently from each other remain undefined.
You would have an easier time learning the SCSI protocol with an analyzer and a few hundered devices (that all speak SCSI differently) than you would by reading the spec. In fact, unless you're doing the most basic of block device operations, I'd say it is impossible to write a fully working SCSI implementation (target or initiator) from the spec alone.
Hardly useless.
Who said useless? The problem is that we can't live without it because we don't have something better around that would make it useless.
Why does this require a monthly fee? Once it's "just working" why do you need to pay more to keep it that way?
Do you pay a monthly fee for you DVD player to just work? Your microwave? Your sofa?
The PIC is a complete solution, supported through a local service provider
Look! It's got recurring revenue generation built in! Not only can you pay for it up front, but you can keep paying for it month after month; forever! ALl the while you'll be giving control of it over to your favorite ISP, who can reduce it's functionality at their whim, or upon lawsuit, whichever comes first.
Where do I sign up?
(Also: How long until Microchip slaps them with a trademark suit?)
I'm under the impression that this type of argument is usually refered to as the "straw man." You redefine the issue ("there is only one reason for having specs and it is this") to something that you can refute, refute it, and then declare victory.
I'd have to be wrong about the purpose of specs for this to be the case.
So are we saying whoever gets there first wins? I.e. if you are the first to define a protocol in code, everyone else must follow what you've said?
Hell, no. Why wouldn't the code go through the draft/revision process like a spec? Or like open source software tends to go through already?
Admitedly, my point is moot when it comes to closed/commercial applications.
Or perhaps we might call upon the invisible hand of the market to decide. Saying everyone code their solution to the problem... and whatever is used becomes the de facto standard. But doesn't this imply that a lot of people will spend a lot of time creating code that will never be used? Is this really the most efficient process?
What were you saying about straw-man arguments?
That the goal of development can be agreed upon before any development starts so that more than one solution can be available at the same time.
Defining requirements is not the job of a spec. A spec sets out the technical details required for use or interoperability. A requirements document has a much smaller scope. Generally the requirements end up being merely the introduction to a spec, if not a completely seperate document.
In fact for closed-source code I think this is as strong a reason as the one you posit.
No matter how dysfunctional the process generally becomes, I would not argue that specs are useless in a closed source environment. I didn't think that was what we were talking about though.
Who needs to consum it when you can just copy the code? Really, if you want something low impact, write a requirements document and leave the technical details up to the implementor. If your spec is specific enough to allow the consumer to anticipate every concievable situation, it will be just as complex as the code. If your spec isn't specific enough to allow the consumer to anticipate every concievable situation, then you will have incompatabilities, or tons of pre-required knowledge.
So you imply that specs contain no errors? Likewise, this is never true.
POSIX, like most specs, is designed to allow software to be both closed-source, and compatible. When your code is available, the sole traditional reason for specs is gone.
Specs that are written by a group of competing organizations are worse than obsolete. They're disaterous. A lengthy revision process slowly, but completely removes all but the most necessary of the specifics from the document in order to match as closely as possible the existing technology from all parties involved. This leads to standards compliant compatibility nightmares. Look at SCSI for a perfect example of this.
Code examples are always better than specs because they are unambiguous. Better yet if the code is commented when the reasoning is unclear. Code combined with a spec can't hurt if the code is the ultimate authority, but what's the point?
How does that make things better?
It hardly makes things better at all if you leave out all the rest of the benefits when you quote my comment, but it's still a benefit. Mining uranium is easy, technologically speaking, when compared to drilling under the surface of the ocean. Plus you need far less material to extract the same amount of energy. Also, It sometimes exists in places we were mining anyway for things like coal.
Anyway, you don't drill for it. Generally you use explosives and large trucks.
The problem that won't go away in 2007 is the winter demand for heating oil, which cuts into the diesel supply, since they're refined from similar weight crude content. Further natural gas development would help, but too many people are paranoid about it.
You know what else would help? Nuclear power. If nuclear power were abundant, we could heat our houses without any fossil fuels or carbon emissions at all. We wouldn't need to drill for natural gas, and our oil consumption would be signifigantly reduced.
Don't forget that basically every present console is selling at a loss and I am pretty sure they have been from day one.
I'd love for you to show proof, but you can't because there is none.
Word is that the PS2 hardware is profitable now, and was within a year, and that the GameCube was profitable on day 1. Microsoft, however, has not only lost money on the hardware for Xbox, but they haven't come close to making it back on game royalties. They've lost billions. I'm fairly certain that they won't let that be the case for the 360, or if they do they'll have to answer to their shareholders and respond to anti-dumping lawsuits from Sony and Nintendo.
Even if they are breaking even, their long term pricing flexability is incredibly low, because unlike Sony, Microsoft has to buy all the parts for the 360. That means when manufacturing costs go down there's another player that takes a cut of the cash. Manufacturers that control the entire supply chain, however, get all the benefit and flexability of increased manufacturing efficiency.
Everything I have heard so far seems to point that Microsoft is making a nice profit at the prices listed
It would be surprising if they were doing better than breaking even. Those graphics chips and processors aren't free, you know, and they're buying them from a third party. A third party who *is* turning a profit on the hardware.
And what games do you know of that require the HDD?
None. But that wouldn't really be the kind of thing they'd advertise. We'll have to wait and see on this one. I can think of some that will have trouble without it... Or will at the very least use TONS of memory card. I'm also certain that some of the games that have been announced were designed under the assumption that the hard drive would be in the default configuration. Imagine playing a game like Oblivion with no hard drive. It can't be pretty.
BTW, it will be retailers who will most likely be eating return cost not Microsoft.
That's funny. You do know that Wal-Mart could crush Microsoft like a bug if they wanted to, right? Nearly zero retail profit margin, and they have to eat the loss on returns? Not likely. Not if Microsoft wants Wal-Mart to sell any of these things (And guess where 80%+ of them will be sold...). I bet Wal-Mart doesn't even have to eat the losses when they mark down the games. I'm sure they have deals set up that would turn places like EB green with envy.
Additionally, we're not going to get the chance to play demos for the system until February of 2006.
Actually, the article didn't even come close to saying that. It said:
When asked if there would be any changes to the February PS3 event where playable demos will be on hand, Saeki did not respond directly. However, he did say that SCE is planning something for the event that is sure to be a "major" surprise.
That could mean there will be demos sooner, or that you won't even get demos in February. It doesn't mean what the summary says.
Can we mod this article as "Troll"?
But like the theories go, expect Halo 3 and a price drop just as PS3 is coming out.
If so, expect a Microsoft shareholder revolt shortly afterward...
Xbox was allowed to lose billions of dollars over the console's lifespan to prime the market for version 2. You really think Microsoft can get away with not turning a profit on the 360 too? Why are they in the business then?
If Microsoft had even the least little bit of flexability in the pricing, you wouldn't have seen them fuck themselves by releasing two versions the way they did. I'll be extremely surprised if we see a price drop on the 360 before Christmas 2006, and even then I'd be surprised if it was more than a $50 drop.
As it is, if they don't make every game work flawlessly without the hard drive, they'll be lucky if the thing still exists after this Christmas. Parents are going to buy their kids the cheap one, and every time a game doesn't work right because they didn't get the expensive one, Microsoft is going to have to eat the cost of a return.
Then, a day or two ago both Microsoft and Sony announced support for the competing HD DVD format, and suddenly Sony has real competition in a fight that looked to be a foregone conclusion in their favor.
This crap gets propgated because the trade rags love a format war.
The Microsoft/Intel announcement was meaningless. It didn't sat "exclusive" in there. Windows will support both. The whole story was a cover so they could slip that fact that the release date for HD_DVD devices was getting pushed back again under the radar.
As such, any speculation based on this announcement is bogus.
I think your conclusion about the prices is exactly correct, but the reasoning is suspect.
Uh. The 41% was one guy, and the 59% was 5 guys. This one guy was taking home 41% of the cash while the other people (who probably worked just as hard for it) had to split the remaining 59% five ways... And it seems like they didn't even have a problem with it until he tried to cash out at massive profit for himself and massive profit divided by five for everybody else.
Did he think they'd send him a fruit basket for that?
If you started a company with five other guys, and one of them was taking home $3.5 mil in profits every year, while you only got $300k, what would you be thinking?
1) You mean the forums where the people with problems bitch, but the people who have no trouble don't bother posting in?
2) I meant in general. Of course there are exceptions.
3) Yeah. I use versamail though, and it works just fine with exchange.
4) The IT department just sets it up. The user only needs to know which of the four buttons on the front to push.
5) I have a Treo 650 from the day they came out. You're full of shit.
11) See #1
Open it up and see for yourself why it's so big.
It's mostly screen and battery. If the iPod nano had to transmit over RF constantly, it would be a lot bigger too.
Palm knows how to make things tiny. Look at the Tungsten T3. I think the only real way they could slim the treo down is if they made the case out of some thin metal.
discovers that they can't do the simple and obvious things that they had come to expect that they could do with it; like backing it up
Would you please stop using this example?
Most people don't make backups. It's a fact of life, and it's well known. That means every time you break out the "backups argument" it's automatically parsed into the piracy argument by practically everybody. From the point you mention backups on, you've lost all credibility with everbody except for the people who already agree with you.
When you're talking about music, talk about using it in your car. Talk about mix CDs. Talk about the iPod... Don't talk about backups!
When you're talking about images or video, talk about watching them in the car. Talk about watching them on your computer. Talk about getting a print made at the local photo shop. Talk about sharing home video made on your camcorder with the family. Don't use the word backups!
No way. The Treo 600/650 STINKS!
Say what you will, practically everybody that used to carry a Blackberry, now carries a Treo. That's a technical success. How Palm has turned that into a losing business is the story.
Except for #4, BTW, everything you listed is either incorrect, or irrelevant. I'll enumerate:
1) Bluetooth works fine on the 650. Especially with the latest software
2) People are upgrading from Blackberrys, not older Treos, so this is irrelevant.
3) Every executive I know with a Treo runs third party e-mail software from Goodlink
4) Bullshit. Besides, company IT departments handle this.
5) What? This is just wrong. (Maybe it's true on Verizon?)
6) How is this different from any other device?
7) Wrong.
8) See #3
9) See #2
10) See #4
11) See #1
Buy what you like, but that won't change the fact that they've sold tons of these things already.