Apple is moving the computer interface in a new direction. Apparently they were not satisfied with one, two, three (lets add some more!) button mice. I can imagine them asking what the value was of having "a little tiny keyboard that you slide around your desk", and subsequently deciding to do something different.
Oddly they've taken the "multiple buttons is confusing" approach and leapt off a cliff. Have you watched a new user try to figure out one of the new apple trackpads? There is so little feedback that they have a hard time even understanding that there is a button available... and its seriously too bad if they meet up with a highly customized desktop supporting multiple gestures. I've noted that even experienced users need to take some time to figure out a peers configuration (concerning which corners do what).... but can you imagine what will happen as the gestures themselves become more and more customizable and as applications add their own gestures to the mix?
This leads to my greatest complaint about the new Magic Mouse -- it doesn't behave the same as a trackpad. In effect having pushed back on movable "mice keyboards" they've also neglected to build a moveable "mice trackpad". Just because it is mounted onto a "mouse" and can be slid around on the desk is no reason, in my book, to introduce a bunch of different gestures and actions. I think they should instead simply mount a full featured trackpad there in mouse form factor. Rather than build their own set of "here is how gestures might be different on this device" instead they should have focused on making gestures customizable in general.
We don't have a mechanism for customizing gestures today and I think there is a lot of software research on making that interface work better.... the hardware needs to be stabilized for a bit longer before that will happen though. I hope to see it soon.
(All this, by the way, leaves your average windows trackpad in the dust; and it is good to see MS is at least experimenting with the ideas. I hope they find the flaws in Apples approach rather than trying to leapfrog in an entirely new direction).
From the article: "Indeed, where Android's browser makes sense on a smartphone's touchscreen, it just doesn't translate here. The process of clicking and holding the left mouse button, while pushing up to scroll the page down, seems clunky and counter-intuitive,"
Gosh, they took an OS designed for a touchscreen and tried a simplistic hack to make it work with a touchpad... and this isn't easy to use? Well, duh. This says nothing about Android and everything about the marketing folks that messed up.
I'll avoid the pissing contest about the CA/certificate vendor business model and concentrate on the technical question asked.
A self-signed SSL certificate should not be used.
The reason for this is that the IETF RFC's that define certificate path validation [see RFC5280] do not specify how to validate an 'end-entity' self-signed certificate. Each browser vendor implements their own logic in this area and _even_ if one assume they all do something reasonable the differences could cause a support nightmare.
A better solution is for the web site to run their own CA. This is very easy and there are many free or mostly free CA products to choose from. Openssl for example would work fine. Distribution of a new root CA is something all the browser's and operating systems support and one has a hope of making that work correctly.
Of course, as others have noted, the "proper" distribution of a CA certificate is debatable. Getting your new CA certificate shipped with the browsers is of course the approach CA/certificate vendors use. It is probably best but cost prohibitive and of course inappropriate for this scenario. The web site is best off if they can widely distribute their CA certificate or distribute it using an existing certificate from a CA vendor (ha!).
Simply distributing it on their own web page puts them squarely into the 'ssh' model wherein the first time somebody connects they get the CA certificate and from ever on they shouldn't have to go through that process again (if they do have to do it again it is a sign of a possible mitm attack). This is a well recognized model and arguably the web browsers should include UI to help support it -- but they do not.
Which means the users are being expected to handle and understand these issues. At which point perhaps the customers would appreciate it if the web site vendor spent that small sum of money and just bought a certificate from an established CA.
> Where would you like your 5 copies of Mac OS X sent?
"Flamebait"? Well, maybe. But I think the are right that Mac OS X is pretty much what the original poster wants. It is Linux "like" and it can run Windows applications 'natively' in a VM. Something that is so well integrated and the applications appear to run side by side. With enough memory you can pretty much have backwards compatibility and eat your cake too.
I'm ambivalent about these licensing limitations. For $99 you can get a development license and run whatever you want on your phone. I'm hoping, and expecting, that somebody will figure out how to use the dev license to drop applications onto the phone directly instead of using Xcode development tools -- but even that wouldn't be a bad thing. Just think, if compiling on Xcode is how one gets the really interesting applications onto the phone then source distributions are automatically the default and everybody is encouraged to have a development environment etc. Isn't this the theory behind certain Linux distributions like Gentoo?
So this sets up a tiered ecosystem where many/most folks get only "safe" applications from the App Store and everybody else gets to load whatever they want using the dev license. (And of course I expect the jailbreak folks to continue their struggles to keep that free as well).
More curious to me is if the Dev license will let me build an application that can run in the background. I understand the reasoning but would rather they took an approach like limiting the amount of memory/processing a background app gets to use. I think are many really innovative ideas to explore in the 'always on' mobile space and apple is needlessly restricting their platform from being part of that wave.
somebody said: > if there was a pair of LED's in the upper left corner of the vehicle, that indicated "at/above speed limit" > or "below speed limit" this would solve many problems
You have a logic failure:
1. If the 'speed limit' is 65 and the flow of traffic is about 55 then everybody's lights would be "red" and there would be no wave visible. Existing brake lights provide an approximation that is more direct than your suggestion.
2. You assume that people actually look this far ahead and think while driving. Many many folks just watch the car directly in front of them. No "solution" that depends on changing the non-forced behavior of the drivers will work. (An example of a forced solution would be the access ramp lights that make people stop before getting on the freeway -- people hate them and would never do that voluntarily even though they work).
We need to invent cars that drive themselves and then the driver can watch a movie and let the robotic algorithms take over the world.
This would move developers away from Microsoft's proprietary APIs and functionalities, aka their lock-in. The end result would be developers writing 'GNU' type code and expecting it to run on either Vista or any 'Unix' environment. Suddenly Vista has to compete on its own merits and can't depend on "killer applications" to pull people in.
Although I think this a good thing, and Apple thinks this a good thing, and Linux thinks this is a good thing I'll be a bit surprised if somebody at Microsoft has convinced enough leads that they now think it is a good thing.
A core phone should be as small and sexy as possible - like the iphone or razor (in its past life). Small is good while maintaining as much functionality as possible. This is clearly the trend. On this core device various extensibility options must exist. For example larger batteries, external keyboards, handfree kits, 'bling' headsets, cool cases etc. Again this trend already exists and is being built on various dock connectors, including usb, and wireless mechanisms like bluetooth.
This Modu thing is just a gimick -- they're marketing the existing trend as 'innovative'.
Simply display any copyrighted material on your person and then have the *AA use the DMCA to sue the bastards out of existence! Wait, wouldn't this constitute knowingly causing copyrighted material to be distributed over a video surveillance network? I'm betting the *AA lawyers are at your door as I type. It was nice knowing you.
If there was a standard (opensourced) API for communicating with WidgetX -- and some form of opensource WidgetControler application was available -- then a competitor can step in with WidgetY and offer much the same user experience (it's even running the same software)!
The status quo lets the WidgetXControler application be part of the offering. The box can read: "Includes the award wining WidgetXControler software that only we provide!".
I'm suspect this was sarcasm:
We'd probably need some sort of halfway point between the Moon and Mars, but that's totally different from this.
Funny how people, even on page, seem to think an orbiting station "halfway between the Earth and Moon" would be useful too. I suspect they won't be useful at all until we have something we really need/want to do in a zero-G environment for long periods of time.
Use a three layer approach: (1) some boot loader ROM sufficient for launching or reloading the firmware (2) the EEPROM firmware (3) all the OS stuff. That way in a 'brick' situation you can always drop back to the ROM to reload the EEPROM firmware. This costs a bit more money though and I can see why a company would save on the costs of the ROM etc and just figure on some small percentage of devices getting accidentally bricked (power outage during firmware update) and dealing with them as warranty cases.
Interestingly for all this talk of communication and whatnot none of you IT defenders have wondered what tools I might be wanting to use, or why I think they're better. Although a few of you have noted my continued statements about working together (yes - this is clearly the way things need to work) as many of you have continued the unfortunately typical IT powerplay.
The software I've selected is Linux. I'd like to be able to use this as my development environment and tool-set since it is a better match for my engineering job tasks. Or, on my laptop, I prefer Mac OS X. IT forcing me to use MS Windows is insane -- and yet it is frequently the case that MS Windows only solutions are actively deployed.
I understand of course why some people like Windows. I was even a Windows developer for a while. So I agree expending some resources on maintaining the Windows world makes sense. But my particular pet peeve is when IT rolls out yet another Windows only tool or web page and simply refuses to work with me on a solution.
Actually I am in engineering. Not all 'users' are equal and certainly not all are clueless computer illiterate 'pointy haired' types. My peers are engineers and we are often in a battle with IT to use realistic tools on our network.
I wonder how much money IT would save if they stopped rolling out stuff we don't need or want.
"Users" in an organization should be the boss. In most cases they do the work that creates funding that IT spends (as overhead). If existing IT organizations continue to fail at providing services I hope all those 'free market' theories are true and they get replaced (soon!).
There is hardly anything more frustrating than having to convince an ignorant, two-bit, power starved, IT nitwit that forcing yet another MS Windows only "solution", that they've been brainwashed into buying from their local MS sales force, is a waste of resources. I swear sometimes I suspect that many people in IT are so focused on freeing up time to read slashdot that they no longer care about doing their job.:)
Obviously I'm speaking in generalities here. Half the problem is probably companies that get too large for effective communication. And then once organizations get entrenched they stop listening to each other. Back when I worked at small companies it was as often the engineers taking turns handling IT tasks -- and we didn't have these conflicts.
IT should be a reactive service. Ideally there would be more communication than just "please install this", maybe something more like, "we need this service and think this would provide it". But frankly I'm tired of IT thinking they know more about my job, and what I need, than I do.
If your current IT environment isn't capable of supporting my needs then fix it.
Although most (all) web servers certainly provide tools for logging ip addresses (and failing that I wonder if the network layer couldn't be used to log connections) you have a point here that closed source software might make it extra difficult to enable logging. For open source technical skills are not an issue as you can always hire somebody to make the appropriate modifications (and in this case I believe **AA would have to pay the fees).
Does this then become a case for using limited functionality close source applications and thus forcing the **AA etc to include another company in the lawsuit? If the **AA really does need to foot the bill then buying a full new software load to "upgrade" to a more functional (logging enabled) set of applications would, at a minimum, make the costs rise. It would be interesting to know if all these costs really can be pushed back to the **AA.
Folks,
From TFA, we see the following, "[Torrentspy] argued that the log data wasn't available, since it existed only in RAM, and as such, was never stored". The judge, being nobodies dummy, accurately noted that this isn't an impediment to logging that data in the future and has ordered them to do so.
Funny jokes about handing over DIMMs aside this is a totally reasonable concept. How many of you all think it's actually impossible to log a number that is in RAM? Are all you/. l33t programmers incapable of writing a variable out to a file?
According to wikipedia [wikipedia.org] security is a problem with the spec itself. It's getting so bad that some major router manufacturers are disabling the routing of UPnP packets by default on their non-consumer (and a few consumer) networking appliances.
This would jive with our suspicion that this feature existed but was never used. The truth would take more investigation. Shrug. Unless something stops working I don't think I'll worry too much about it.:)
If you follow the link to the apple security update page there are actually two vulnerabilities associated with UPnP IGD. For one of them apple indicates that "this update addresses the issue by performing additional validation when processing UPnP protocol packets in iChat". For mDNSResponder apple indicates "this update addresses the issue by removing UPnP IGD support.
Clearly something is unclear since iChat is obviously still using UPnP IGD, likely as a client?
But why is the mDNSResponder using UPnP IGP anyway? mDNS is for service discovery etc and is basically a competitor to UPnP (I thought). Perhaps there is a way for mDNSResponder to leverage UPnP IGP to broadcast service messages (e.g. bonjour) across a local NAT? If so I've never seen nor heard of this working -- so perhaps what they're disabling is vulnerable code that wasn't doing anything anyway?
the president who must have access to a mean supply of weed because you can see how worried he's been looking lately If you had access to a mean supply of weed you wouldn't look worried at all. Dude, it's all good.
From the article, "Microsoft products still getting mainstream support -- meaning software within the first five years of its release -- have received free patches. But operating systems and applications now getting what Microsoft dubs extended support receive only security fixes for free; Corporate customers who want non-security patches must fork over large fees to Microsoft."
The question here is not if they should charge for this patch; it is reasonable to do so. The issue is how much? Clearly there are costs involved with opening up old development branches, recreating build environments, developing fixes, doing test, and then distribution. Additionally this is for a relatively small segment of the market who are primarily running old software who haven't paid anything to Microsoft in years. From that perspective their argument that 'if you want a non-security fix you must pay good $$ for it' kinda makes sense. I suspect they're trying to push smaller organizations with 10s or 100s of machines to consider an upgrade to a newer, supported, operating system.
Of course this isn't a totally solid argument. Clearly they do already have some infrastructure in place for doing fixes; because they're still turning out security patches. And who could honestly argue there aren't security issues in these older products? So, why aren't they charging for security patches? Is a time issue no less important?
This is a grey area and my personal opinion is that a more 'customer focused' organization would do this fix for free or for a minimal fee. The original $40K charge was clearly highway robbery and this $4k still seems inflated; especially since they know it will be amortized across every user of the older systems. I think this behavior is yet another sign that Microsoft is complacent in their monopoly status; much the same way they've embraced DRM. They assume everybody will, of course, use their products and therefore their primary focus is about making the most of their monopoly. In this case keeping people locked into the current product and/or charging them for using older products; in the DRM case forcing DRM on people so they can woo the content providers.
Historically they've done well with these tradeoffs. Even mostly running linux & mac systems I still find myself occasionally needing windows (currently via parallels). It will be interesting to see how if their focus shifts over the years. It takes a long time to change a large organization.
Slashdot Mirror
Apple is moving the computer interface in a new direction. Apparently they were not satisfied with one, two, three (lets add some more!) button mice. I can imagine them asking what the value was of having "a little tiny keyboard that you slide around your desk", and subsequently deciding to do something different.
Oddly they've taken the "multiple buttons is confusing" approach and leapt off a cliff. Have you watched a new user try to figure out one of the new apple trackpads? There is so little feedback that they have a hard time even understanding that there is a button available... and its seriously too bad if they meet up with a highly customized desktop supporting multiple gestures. I've noted that even experienced users need to take some time to figure out a peers configuration (concerning which corners do what).... but can you imagine what will happen as the gestures themselves become more and more customizable and as applications add their own gestures to the mix?
This leads to my greatest complaint about the new Magic Mouse -- it doesn't behave the same as a trackpad. In effect having pushed back on movable "mice keyboards" they've also neglected to build a moveable "mice trackpad". Just because it is mounted onto a "mouse" and can be slid around on the desk is no reason, in my book, to introduce a bunch of different gestures and actions. I think they should instead simply mount a full featured trackpad there in mouse form factor. Rather than build their own set of "here is how gestures might be different on this device" instead they should have focused on making gestures customizable in general.
We don't have a mechanism for customizing gestures today and I think there is a lot of software research on making that interface work better .... the hardware needs to be stabilized for a bit longer before that will happen though. I hope to see it soon.
(All this, by the way, leaves your average windows trackpad in the dust; and it is good to see MS is at least experimenting with the ideas. I hope they find the flaws in Apples approach rather than trying to leapfrog in an entirely new direction).
Nobody expected it, I guess.
Nobody expects the Spamish Inquisition!!
From the article:
"Indeed, where Android's browser makes sense on a smartphone's touchscreen, it just doesn't translate here. The process of clicking and holding the left mouse button, while pushing up to scroll the page down, seems clunky and counter-intuitive,"
Gosh, they took an OS designed for a touchscreen and tried a simplistic hack to make it work with a touchpad... and this isn't easy to use? Well, duh. This says nothing about Android and everything about the marketing folks that messed up.
- So I'd have a convenient location to display all the system monitoring stuff I like to run.
- So I could display videos I'm only 'sorta' watching
- Because it would be cool
- (make one up)
I'll avoid the pissing contest about the CA/certificate vendor business model and concentrate on the technical question asked.
A self-signed SSL certificate should not be used.
The reason for this is that the IETF RFC's that define certificate path validation [see RFC5280] do not specify how to validate an 'end-entity' self-signed certificate. Each browser vendor implements their own logic in this area and _even_ if one assume they all do something reasonable the differences could cause a support nightmare.
A better solution is for the web site to run their own CA. This is very easy and there are many free or mostly free CA products to choose from. Openssl for example would work fine. Distribution of a new root CA is something all the browser's and operating systems support and one has a hope of making that work correctly.
Of course, as others have noted, the "proper" distribution of a CA certificate is debatable. Getting your new CA certificate shipped with the browsers is of course the approach CA/certificate vendors use. It is probably best but cost prohibitive and of course inappropriate for this scenario. The web site is best off if they can widely distribute their CA certificate or distribute it using an existing certificate from a CA vendor (ha!).
Simply distributing it on their own web page puts them squarely into the 'ssh' model wherein the first time somebody connects they get the CA certificate and from ever on they shouldn't have to go through that process again (if they do have to do it again it is a sign of a possible mitm attack). This is a well recognized model and arguably the web browsers should include UI to help support it -- but they do not.
Which means the users are being expected to handle and understand these issues. At which point perhaps the customers would appreciate it if the web site vendor spent that small sum of money and just bought a certificate from an established CA.
> Where would you like your 5 copies of Mac OS X sent?
"Flamebait"? Well, maybe. But I think the are right that Mac OS X is pretty much what the original poster wants. It is Linux "like" and it can run Windows applications 'natively' in a VM. Something that is so well integrated and the applications appear to run side by side. With enough memory you can pretty much have backwards compatibility and eat your cake too.
I'm ambivalent about these licensing limitations. For $99 you can get a development license and run whatever you want on your phone. I'm hoping, and expecting, that somebody will figure out how to use the dev license to drop applications onto the phone directly instead of using Xcode development tools -- but even that wouldn't be a bad thing. Just think, if compiling on Xcode is how one gets the really interesting applications onto the phone then source distributions are automatically the default and everybody is encouraged to have a development environment etc. Isn't this the theory behind certain Linux distributions like Gentoo?
So this sets up a tiered ecosystem where many/most folks get only "safe" applications from the App Store and everybody else gets to load whatever they want using the dev license. (And of course I expect the jailbreak folks to continue their struggles to keep that free as well).
More curious to me is if the Dev license will let me build an application that can run in the background. I understand the reasoning but would rather they took an approach like limiting the amount of memory/processing a background app gets to use. I think are many really innovative ideas to explore in the 'always on' mobile space and apple is needlessly restricting their platform from being part of that wave.
somebody said:
> if there was a pair of LED's in the upper left corner of the vehicle, that indicated "at/above speed limit"
> or "below speed limit" this would solve many problems
You have a logic failure:
1. If the 'speed limit' is 65 and the flow of traffic is about 55 then everybody's lights would be "red" and there would be no wave visible. Existing brake lights provide an approximation that is more direct than your suggestion.
2. You assume that people actually look this far ahead and think while driving. Many many folks just watch the car directly in front of them. No "solution" that depends on changing the non-forced behavior of the drivers will work. (An example of a forced solution would be the access ramp lights that make people stop before getting on the freeway -- people hate them and would never do that voluntarily even though they work).
We need to invent cars that drive themselves and then the driver can watch a movie and let the robotic algorithms take over the world.
This would move developers away from Microsoft's proprietary APIs and functionalities, aka their lock-in. The end result would be developers writing 'GNU' type code and expecting it to run on either Vista or any 'Unix' environment. Suddenly Vista has to compete on its own merits and can't depend on "killer applications" to pull people in.
Although I think this a good thing, and Apple thinks this a good thing, and Linux thinks this is a good thing I'll be a bit surprised if somebody at Microsoft has convinced enough leads that they now think it is a good thing.
A core phone should be as small and sexy as possible - like the iphone or razor (in its past life). Small is good while maintaining as much functionality as possible. This is clearly the trend. On this core device various extensibility options must exist. For example larger batteries, external keyboards, handfree kits, 'bling' headsets, cool cases etc. Again this trend already exists and is being built on various dock connectors, including usb, and wireless mechanisms like bluetooth.
This Modu thing is just a gimick -- they're marketing the existing trend as 'innovative'.
My guess is 'differentiation'.
If there was a standard (opensourced) API for communicating with WidgetX -- and some form of opensource WidgetControler application was available -- then a competitor can step in with WidgetY and offer much the same user experience (it's even running the same software)!
The status quo lets the WidgetXControler application be part of the offering. The box can read: "Includes the award wining WidgetXControler software that only we provide!".
Funny how people, even on page, seem to think an orbiting station "halfway between the Earth and Moon" would be useful too. I suspect they won't be useful at all until we have something we really need/want to do in a zero-G environment for long periods of time.
Use a three layer approach: (1) some boot loader ROM sufficient for launching or reloading the firmware (2) the EEPROM firmware (3) all the OS stuff. That way in a 'brick' situation you can always drop back to the ROM to reload the EEPROM firmware. This costs a bit more money though and I can see why a company would save on the costs of the ROM etc and just figure on some small percentage of devices getting accidentally bricked (power outage during firmware update) and dealing with them as warranty cases.
Interestingly for all this talk of communication and whatnot none of you IT defenders have wondered what tools I might be wanting to use, or why I think they're better. Although a few of you have noted my continued statements about working together (yes - this is clearly the way things need to work) as many of you have continued the unfortunately typical IT powerplay.
The software I've selected is Linux. I'd like to be able to use this as my development environment and tool-set since it is a better match for my engineering job tasks. Or, on my laptop, I prefer Mac OS X. IT forcing me to use MS Windows is insane -- and yet it is frequently the case that MS Windows only solutions are actively deployed.
I understand of course why some people like Windows. I was even a Windows developer for a while. So I agree expending some resources on maintaining the Windows world makes sense. But my particular pet peeve is when IT rolls out yet another Windows only tool or web page and simply refuses to work with me on a solution.
I wonder how much money IT would save if they stopped rolling out stuff we don't need or want.
"Users" in an organization should be the boss. In most cases they do the work that creates funding that IT spends (as overhead). If existing IT organizations continue to fail at providing services I hope all those 'free market' theories are true and they get replaced (soon!).
There is hardly anything more frustrating than having to convince an ignorant, two-bit, power starved, IT nitwit that forcing yet another MS Windows only "solution", that they've been brainwashed into buying from their local MS sales force, is a waste of resources. I swear sometimes I suspect that many people in IT are so focused on freeing up time to read slashdot that they no longer care about doing their job. :)
Obviously I'm speaking in generalities here. Half the problem is probably companies that get too large for effective communication. And then once organizations get entrenched they stop listening to each other. Back when I worked at small companies it was as often the engineers taking turns handling IT tasks -- and we didn't have these conflicts.
If your current IT environment isn't capable of supporting my needs then fix it.
Does this then become a case for using limited functionality close source applications and thus forcing the **AA etc to include another company in the lawsuit? If the **AA really does need to foot the bill then buying a full new software load to "upgrade" to a more functional (logging enabled) set of applications would, at a minimum, make the costs rise. It would be interesting to know if all these costs really can be pushed back to the **AA.
Folks, From TFA, we see the following, "[Torrentspy] argued that the log data wasn't available, since it existed only in RAM, and as such, was never stored". The judge, being nobodies dummy, accurately noted that this isn't an impediment to logging that data in the future and has ordered them to do so. Funny jokes about handing over DIMMs aside this is a totally reasonable concept. How many of you all think it's actually impossible to log a number that is in RAM? Are all you /. l33t programmers incapable of writing a variable out to a file?
This would jive with our suspicion that this feature existed but was never used. The truth would take more investigation. Shrug. Unless something stops working I don't think I'll worry too much about it.
Clearly something is unclear since iChat is obviously still using UPnP IGD, likely as a client?
But why is the mDNSResponder using UPnP IGP anyway? mDNS is for service discovery etc and is basically a competitor to UPnP (I thought). Perhaps there is a way for mDNSResponder to leverage UPnP IGP to broadcast service messages (e.g. bonjour) across a local NAT? If so I've never seen nor heard of this working -- so perhaps what they're disabling is vulnerable code that wasn't doing anything anyway?
The question here is not if they should charge for this patch; it is reasonable to do so. The issue is how much? Clearly there are costs involved with opening up old development branches, recreating build environments, developing fixes, doing test, and then distribution. Additionally this is for a relatively small segment of the market who are primarily running old software who haven't paid anything to Microsoft in years. From that perspective their argument that 'if you want a non-security fix you must pay good $$ for it' kinda makes sense. I suspect they're trying to push smaller organizations with 10s or 100s of machines to consider an upgrade to a newer, supported, operating system.
Of course this isn't a totally solid argument. Clearly they do already have some infrastructure in place for doing fixes; because they're still turning out security patches. And who could honestly argue there aren't security issues in these older products? So, why aren't they charging for security patches? Is a time issue no less important?
This is a grey area and my personal opinion is that a more 'customer focused' organization would do this fix for free or for a minimal fee. The original $40K charge was clearly highway robbery and this $4k still seems inflated; especially since they know it will be amortized across every user of the older systems. I think this behavior is yet another sign that Microsoft is complacent in their monopoly status; much the same way they've embraced DRM. They assume everybody will, of course, use their products and therefore their primary focus is about making the most of their monopoly. In this case keeping people locked into the current product and/or charging them for using older products; in the DRM case forcing DRM on people so they can woo the content providers.
Historically they've done well with these tradeoffs. Even mostly running linux & mac systems I still find myself occasionally needing windows (currently via parallels). It will be interesting to see how if their focus shifts over the years. It takes a long time to change a large organization.
- max
That is the way language works. Get over it.