Most of these comments are way off-topic.
Whether or not this is a good method of distributing
DVDs is not the issue, nor is whether anyone should
anyone for movies at all, or how good various companies
are at delivering on what they promise.
The real issue is that however good this business
model is or isn't, there is absolutely nothing
that is technically innovative about it. It is a simple
billing model -- something that is explicitly
not patentable.
This doesnt' even call for congressional action.
Firing half of the patent department for technical
incompetence and failure to read the laws they
are supposed to be enforcing would be more appropriate.
Only if they signed a contract.
Now of course, before digital distribution
they really didn't have any other choice.
The record companies
had an effective monopoly on the channels of distribution.
The long-term promise of digital distribution is not the opportunity to avoid paying for music, but eliminating the bottlenecks between artists and their fans.
We're already very close to a state where an established artist can easily make a living just producing their music.
What we still need to see if the development of mechanisms
where artists can become known to listeners that's not
dependent on one form or another of payola to radio
stations.
If an Oil company tries to sell you a tanker truck at a time,
you'll cross the street and buy a few gallons from the other
oil company.
Oil companies trying to sell you a tanker truck at a time
would only be a problem if they colluded, and refused
to compete.
There are sufficiently few oil companies that this can be
a concern, and historically has been on other issues.
The thought of musicians colluding successfully to
deny their music to consumers is just so far fetched
as to be laughable. If they were capable of doing so
they wouldn't have needed digital distribution to
fire the distributors in the first place.
If a writer wants to produce novels, nobody demands
that he sells it a chapter at a time. If a musician thinks
of an album as a complete work, they should be allowed
to sell it that way. The real issue is when the marketing
channel determines how works can be presented. For example, it makes it hard for writers to sell short stories.
Marketing forces may indeed make it hard for musicians
to sell "opus length" compositions that contain multiple
songs. But it's still their decision.
Digital distribution has the potential to eliminate
most of the middlemen, allowing artists to efficiently
distribute thier work directly to the audience.
But there is no reason to believe that doing so will
make artists more responsive to the market.
It will probably enable them to pursue their own artistic
visions more.
Which will predicatably result in more artists:
creating works that are not blandly dictated by marketing types, and therefore hopefully more intesting.
firmly believing that their entire album is worth listenting to.
Eventually artists will realize that the album was never a true cohesive work (with a few exceptions where it
had been truly worked on). It was always more of an
arbitrary size for delivery.
In this transitional period artists are left with the worst of both worlds. They still have to delay release and/or push
out a song that wasn't quite ready in order to have "an album", but suddenly they risk their fans not hearing all
the tracks the artist really wanted them to hear.
Well, it's transitional, and the latter problem was already created by radio.
In the meantime, remember that an artists control over their own material is one monopoly that most everyone
should be wiling to support. Done right the shift to
digital distribution should be about increasing
their control, not about ending it.
If they just learned to read each others install lists,
and how to check for what was installed via normal
packages, then they could keep their seperate
codebases.
The OS is Darwin. Lots of different codebases can
use it. The real challenge is managing the classic
Unix problem of ensuring everyone gets the right
version of shared dynamic libraries.
Doesn't cut it. USB 2 was clearly promoted as being
a suitable interface for external disk drives that
could compete with firewire.
A shared 12 Mb/s bus cannot be considered a
realistic interface to multiple external disk drives.
Therefore "USB 2" is no longer in the same league
as firewire.
And 640 KB is more than enough memory for any desktop too,
Try thinking new applications. What if your "desktop" machine is capturing one TV show, downloading a
major update to a software application, and your
viewing two versions of a video in parallel in order
to determine how to further edit the thrid copy that
you have open in another window.
And oh yes, you just received 73 wonderful opportunities
to engage in financial transactions with a former Nigerian minister.
It seems to me that a "desktop" machine could end up
needing quite a bit of internal bandwidth.
Correct. The problems with synchronizing multiple high speed lines is such that virtually all high-speed interfaces
are going serial, or very slightly parallel. The latter are
generally not bit-wise parallel, but synchronize at a greater
granularity. An example of the latter can be found in
4x InfiniBand links.
This also relates to chip design. A certain number of
external pins creates a minimal chip size. Serial interfaces
can be dealt with using less board space. That is the major
plus for Serial ATA. Raw speed wouldn't be much of an
improvement, as that current ATA is mostly bound by
the speed of the disks themselves. The same data over
thinner cable allows more point-to-point connections.
Now USB has put on its web site _ www.usb.org _ a statement that states: ``The correct nomenclature for high-speed USB products is ``Hi-Speed USB.'' The correct nomenclature for low or Full-speed USB products is simply ``USB''. And in the FAQ section it states: ``High speed USB products have a design data rate of 480 Mb/s. Full speed USB devices signal at 12Mb/s.''
Let's see. 12/480 is 1/40th. A very interesting definition of "full".
Having promoted USB 2 as a 480 Mb/s, the appropriate label strikes me as "fraudulent" and "deliberately misleading".
Forthcoming: the automotive industry will improve car mileage and durability by clarifying that a mile is actually
only 1000 feet.
Who decides the degree to which a product is "compliant" with open standards?
Who decides what "open source" efforts
receive the funds?
Who decides what an open standard is?
Could a monoplist declare something to be an open standard, and then just do a sloppy job of providing details?
The major government intervention that I remain in favor of is to require any selling a system to a) disclose all of their external interfaces, and b) provide methods to unload/reload all user data to/from externally editable formats without loss of any semantic data.
Re:Exactly what makes a supplier monopolistic
on
iBox Episode 2
·
· Score: 1
A patent is a legal monopoly for a short time period.
The rationale, whether you accept it or not, is to
promote innovation and the distribution of knowledge.
But it is a monopoly. Consult any economic text.
It's just not an illegal monoply, or necessarily an abusive monopoly.
Re:Exactly what makes a supplier monopolistic
on
iBox Episode 2
·
· Score: 1
Of course it's a monopoly. They are the only supplier
of systems that run Mac OS software.
Just because a market is small does not mean that
you cannot have a monopoly over it.
The important thing is to distinquish between a natural monopoly and one created by anti-competitive products.
A natural monopoly occurs when there are no barriers
to entry of a new supplier, but there is insufficient incentive
for a second supplier to enter the market. You could make
a strong argument that Apple's total market share is still
sufficiently small that nobody could design a clone from
scratch and succeed.
An anti-competitive action would be witholding information
about the interface between the software and the platform.
That would include publishing a misleading spec and not
sharing known errata.
My original point is that if you never sell the parts to
anyone else, only the whole, then you cannot be accused
of being a monopolistic supplier of those parts. The whole
point is that you aren't supplying those parts to the outside
world.
The product you do offer to the word, a platform to run
software, should be documented honestly and completely.
Companies that deliberately fail to do so are acting in a monopolistic anti-competitive fashion.
But you have to be realistic. Nobody can provide perfect specifications. Generally, Apple deserves credit for revealing most of their interfaces in a honest and straigh-forward fashion. Even if they aren't always as easy to
find and search as they could be.
Exactly what makes a supplier monopolistic
on
iBox Episode 2
·
· Score: 1
I see nothing wrong with someone who designs a machine
taking exclusive rights to use the parts of that design.
What would be monopolistic is if you failed to reveal enough information to someone else to design an
alternate computer to run the software on another
platform.
Unfortunately that's the general rule, unless you stick
with open-source software. It would be a great rule
for the FTC to impose.
Requiring product developers to make a market in each
and every one of their component, however, would be
an unreasonable burden. How would you prevent a competitor from sabotaging your supplies by buying
up one minor part? How would you apportion your
R&D costs fairly to each element of the design?
Wouldn't you be at risk of underpricing one element
and giving something away to the competition?
Who is going to generate the specifications for
each part that are adequate for another
assembler to user? Are you obligated to not change
the part?
Making a market for a product has overhead. It would
be unreasonable to require anyone who develops a
composite box to document and market each piece
of their design.
Keep in mind that the economics of manufacturing
overwhelmingly favor non-unique parts already.
The premium of a custom part is not something
that will ever be justified just to block clones.
But the original idea is still intact: Redesigning Linux for use by demanding business customers "is not technologically feasible or even possible at the enterprise level without (a) a high degree of design coordination, (b) access to expensive and sophisticated design and testing equipment; (c) access to Unix code and development methods; (d) Unix architectural experience; and (e) a very significant financial investment," the amended suit say
Four out of the five allegations are perfectly ethical
and legal. Even access to Unix code (c) is legal if
the purpose was to determine requirements and their
was no explicit agreement to the contrary.
Even if you can show that code was copied, you then have
to show that you created the code in the first place, And
then you get to establish damages.
As that nobody knew the code was stolen (if in fact
it was) its hard to see how this damaged SCO. If they
have no patent claim on the algorithms, clearly IBM
could have simply coded it themselves.
One basic principle of law is that you can't benefit
from stealing other's property, even if it was not
done intentionally. So if SCO can show that
they originated this code and that IBM included then
I believe they would be entitled to force IBM to pay
what IBM should have paid somebody to code it
honestly in the first place.
If it was intentional they may be entitled to triple damages.
Wow, we many be talking thousands of dollars here.
QNX is an embedded OS. As embedded OSs go its very complete. You can get far smaller kernels with fewer pre-packaged solutions, and depending on your application that can be preferable.
I haven't double-checked things recently, but my recollection was that QNX emphasized distributed
systems (especially locally distributed, as in within
a factory) more than most kernels. If you're building
a distributed message passing system, QNX is great.
If you're building a real-time state machine, there
are other kernels that might be a better fit.
Kernels are most applicable for applications where
the processor has a very defined purpose and frequently must have very predictable responses.
Linux and BSD can be abused to behave
that way, but their real strength is their flexibiilty.
If you need to add new daemons quickly and be confident
that you aren't breaking other applications, then you want
a "full OS" such as any of the Unixes.
Personally, I've found the "loaded" kernels (such as
VxWorks and QNX) to be of dwindling importance.
When I do a system design I tend to end up with
environments where I want a full Linux or BSD in
order to have the latest in network stacks, or I
want complete and total control of the processor.
In the latter case I want the smallest kernel that
will boot my state machine possible. I don't want
efficient thread context switching, in those environments
I don't want threads, just objects and state transitions.
You are missing an important distinction.
The Desktop is not the OS.
Failure to make that distinction leads to systems
that cannot be administered in any automated
fashion because certain functions / controls
are only available via the desktop.
Apple is certainly guilty of providing skimpy
documentation on how to administer your mac
using only the command line.
If you don't view the Desktop as a GUI frontend
to the OS the answers become very different.
Once seperated from the OS, what does the
Desktop do? It's a display system and it browses
the file system.
And what does a Browser do?
Insisting that the Browser is inherently different
from the Desktop amounts to saying that files
not stored on your local system are not really
files. It's one way to think of things, but it
isn't necessarily the best way.
Now argumenets can be made that Browsing
should be modular and distinct from the windowing
system. But that should apply for local as well as
remote files.
Re: avoiding Ifs with state machines
on
Ageism in IT?
·
· Score: 1
I write everything using state machines.
They can avoid many conditionals, but not all.
Consider that any if expression considers
factors which are:
instance data for the object.
parameters/fields within the stimulus/event
combinations of the above, including intermediate results.
A properly done state design eliminates by ifs that are based solely upon the event data. Seperate events should have been used, resulting in different actions.
An if that was based solely upon instance data
that had values before the event can be eliminated. If based
solely upon data known in advance, It could
have been represented as a seperate state.
However any condition that is based both on
instance and event data is a true conditional and cannot
be eliminated from a state machine.
That is why transition guards and decision points
are found on State Transition Diagrams.
Then you are not opposed to software patents. You are opposed to all forms of Intellectual Property rights.
Far too many patents have been granted for "inventions"
that anyone would have figured out the second they
tried to build a similar product.
That's the problem that needs to be addressed. Patents
are supposed to encourage development of
solutions that would not have otherwise been developed.
What we have instead is severe "first post" problem
that rewards squatters rights rather than true invention.
The biggest change I would make to patent law is to
allow non-adversarial challenges to claims of being
an innovation. Allow public comments to attack
patents, without hiring lawyers, and the abusive
patents won't survive for very long.
But some GPL-backers almost seem seek to forbid others from having retaining any form of proprietary rights
on their inventions.
If the benefits of open-source collaboration are
truly beneficial, then open-source projects will be able
to compete with proprietary solutions without forcing
proprietary systems to do without Intellectual Property
protection.
What needs to be addressed is the rampant practice
of "patenting" product ideas rather than truly innovative
solutions.
In other words, open source software has to be protected
from proprietary software "patenting" problems or "solutions" that were completely obvious. It does not
need to have the right to steal innovations from
proprietary software.
The amount of nuclear material is probably quite small.
There is probably far more risk from any nuclear sub,
or from an invading army that forgets to secure nuclear waste sites.
I never had a problem with incorporating web browser functionality with the desktop. The real issue was always the failure to seperate the desktop from the OS.
Of course, with non-MS systems the OS, the desktop
and browsers are all seperate, or at least
potentially so.
Apple's only "unfair advantage" with Safari is that they
are the Provider of the desktop. Obvously MAC users
are more likely to like Apple's desktop, or to at least
be fully familiar with it. Then there is the additional
advantage of being a familiar brand name.
So I believe the "secret message" here is that MS
considers those factors alone to be an
unbeatable combination. The implications is that
it was all that they needed. (And for anyone who would
buy that argument from them, I have some dotcom
options to unload for a website selling swampland).
Slashdot Mirror
Most of these comments are way off-topic. Whether or not this is a good method of distributing DVDs is not the issue, nor is whether anyone should anyone for movies at all, or how good various companies are at delivering on what they promise.
The real issue is that however good this business model is or isn't, there is absolutely nothing that is technically innovative about it. It is a simple billing model -- something that is explicitly not patentable.
This doesnt' even call for congressional action. Firing half of the patent department for technical incompetence and failure to read the laws they are supposed to be enforcing would be more appropriate.
Only if they signed a contract. Now of course, before digital distribution they really didn't have any other choice. The record companies had an effective monopoly on the channels of distribution. The long-term promise of digital distribution is not the opportunity to avoid paying for music, but eliminating the bottlenecks between artists and their fans.
We're already very close to a state where an established artist can easily make a living just producing their music. What we still need to see if the development of mechanisms where artists can become known to listeners that's not dependent on one form or another of payola to radio stations.
According to the cited article, the "artists" got 20%. The performer got 12% and the song's author got 8%.
I hope you agree that both are artists.
If an Oil company tries to sell you a tanker truck at a time, you'll cross the street and buy a few gallons from the other oil company.
Oil companies trying to sell you a tanker truck at a time would only be a problem if they colluded, and refused to compete.
There are sufficiently few oil companies that this can be a concern, and historically has been on other issues.
The thought of musicians colluding successfully to deny their music to consumers is just so far fetched as to be laughable. If they were capable of doing so they wouldn't have needed digital distribution to fire the distributors in the first place.
If a writer wants to produce novels, nobody demands that he sells it a chapter at a time. If a musician thinks of an album as a complete work, they should be allowed to sell it that way. The real issue is when the marketing channel determines how works can be presented. For example, it makes it hard for writers to sell short stories.
Marketing forces may indeed make it hard for musicians to sell "opus length" compositions that contain multiple songs. But it's still their decision.
It may be foolish, but it's their music.
Digital distribution has the potential to eliminate most of the middlemen, allowing artists to efficiently distribute thier work directly to the audience.
But there is no reason to believe that doing so will make artists more responsive to the market. It will probably enable them to pursue their own artistic visions more.
Which will predicatably result in more artists:
Eventually artists will realize that the album was never a true cohesive work (with a few exceptions where it had been truly worked on). It was always more of an arbitrary size for delivery.
In this transitional period artists are left with the worst of both worlds. They still have to delay release and/or push out a song that wasn't quite ready in order to have "an album", but suddenly they risk their fans not hearing all the tracks the artist really wanted them to hear.
Well, it's transitional, and the latter problem was already created by radio.
In the meantime, remember that an artists control over their own material is one monopoly that most everyone should be wiling to support. Done right the shift to digital distribution should be about increasing their control, not about ending it.
If they just learned to read each others install lists, and how to check for what was installed via normal packages, then they could keep their seperate codebases.
The OS is Darwin. Lots of different codebases can use it. The real challenge is managing the classic Unix problem of ensuring everyone gets the right version of shared dynamic libraries.
Doesn't cut it. USB 2 was clearly promoted as being a suitable interface for external disk drives that could compete with firewire.
A shared 12 Mb/s bus cannot be considered a realistic interface to multiple external disk drives. Therefore "USB 2" is no longer in the same league as firewire.
And 640 KB is more than enough memory for any desktop too,
Try thinking new applications. What if your "desktop" machine is capturing one TV show, downloading a major update to a software application, and your viewing two versions of a video in parallel in order to determine how to further edit the thrid copy that you have open in another window.
And oh yes, you just received 73 wonderful opportunities to engage in financial transactions with a former Nigerian minister.
It seems to me that a "desktop" machine could end up needing quite a bit of internal bandwidth.
Correct. The problems with synchronizing multiple high speed lines is such that virtually all high-speed interfaces are going serial, or very slightly parallel. The latter are generally not bit-wise parallel, but synchronize at a greater granularity. An example of the latter can be found in 4x InfiniBand links.
This also relates to chip design. A certain number of external pins creates a minimal chip size. Serial interfaces can be dealt with using less board space. That is the major plus for Serial ATA. Raw speed wouldn't be much of an improvement, as that current ATA is mostly bound by the speed of the disks themselves. The same data over thinner cable allows more point-to-point connections.
If it's full speed, why do they sell something faster?
According to the article:
Let's see. 12/480 is 1/40th. A very interesting definition of "full".
Having promoted USB 2 as a 480 Mb/s, the appropriate label strikes me as "fraudulent" and "deliberately misleading".
Forthcoming: the automotive industry will improve car mileage and durability by clarifying that a mile is actually only 1000 feet.
Agreed. It sounds great, but...
The major government intervention that I remain in favor of is to require any selling a system to a) disclose all of their external interfaces, and b) provide methods to unload/reload all user data to/from externally editable formats without loss of any semantic data.
A patent is a legal monopoly for a short time period. The rationale, whether you accept it or not, is to promote innovation and the distribution of knowledge. But it is a monopoly. Consult any economic text. It's just not an illegal monoply, or necessarily an abusive monopoly.
Of course it's a monopoly. They are the only supplier of systems that run Mac OS software. Just because a market is small does not mean that you cannot have a monopoly over it.
The important thing is to distinquish between a natural monopoly and one created by anti-competitive products.
A natural monopoly occurs when there are no barriers to entry of a new supplier, but there is insufficient incentive for a second supplier to enter the market. You could make a strong argument that Apple's total market share is still sufficiently small that nobody could design a clone from scratch and succeed.
An anti-competitive action would be witholding information about the interface between the software and the platform. That would include publishing a misleading spec and not sharing known errata.
My original point is that if you never sell the parts to anyone else, only the whole, then you cannot be accused of being a monopolistic supplier of those parts. The whole point is that you aren't supplying those parts to the outside world.
The product you do offer to the word, a platform to run software, should be documented honestly and completely. Companies that deliberately fail to do so are acting in a monopolistic anti-competitive fashion.
But you have to be realistic. Nobody can provide perfect specifications. Generally, Apple deserves credit for revealing most of their interfaces in a honest and straigh-forward fashion. Even if they aren't always as easy to find and search as they could be.
I see nothing wrong with someone who designs a machine taking exclusive rights to use the parts of that design.
What would be monopolistic is if you failed to reveal enough information to someone else to design an alternate computer to run the software on another platform.
Unfortunately that's the general rule, unless you stick with open-source software. It would be a great rule for the FTC to impose.
Requiring product developers to make a market in each and every one of their component, however, would be an unreasonable burden. How would you prevent a competitor from sabotaging your supplies by buying up one minor part? How would you apportion your R&D costs fairly to each element of the design? Wouldn't you be at risk of underpricing one element and giving something away to the competition? Who is going to generate the specifications for each part that are adequate for another assembler to user? Are you obligated to not change the part?
Making a market for a product has overhead. It would be unreasonable to require anyone who develops a composite box to document and market each piece of their design.
Keep in mind that the economics of manufacturing overwhelmingly favor non-unique parts already. The premium of a custom part is not something that will ever be justified just to block clones.
Oh please, Implying that a nut like Orrin Hatch can be bought is just pathetic.
The article sites cites the following allegation:
Four out of the five allegations are perfectly ethical and legal. Even access to Unix code (c) is legal if the purpose was to determine requirements and their was no explicit agreement to the contrary.
Even if you can show that code was copied, you then have to show that you created the code in the first place, And then you get to establish damages.
As that nobody knew the code was stolen (if in fact it was) its hard to see how this damaged SCO. If they have no patent claim on the algorithms, clearly IBM could have simply coded it themselves.
One basic principle of law is that you can't benefit from stealing other's property, even if it was not done intentionally. So if SCO can show that they originated this code and that IBM included then I believe they would be entitled to force IBM to pay what IBM should have paid somebody to code it honestly in the first place.
If it was intentional they may be entitled to triple damages.
Wow, we many be talking thousands of dollars here.
QNX is an embedded OS. As embedded OSs go its very complete. You can get far smaller kernels with fewer pre-packaged solutions, and depending on your application that can be preferable.
I haven't double-checked things recently, but my recollection was that QNX emphasized distributed systems (especially locally distributed, as in within a factory) more than most kernels. If you're building a distributed message passing system, QNX is great. If you're building a real-time state machine, there are other kernels that might be a better fit.
Kernels are most applicable for applications where the processor has a very defined purpose and frequently must have very predictable responses. Linux and BSD can be abused to behave that way, but their real strength is their flexibiilty.
If you need to add new daemons quickly and be confident that you aren't breaking other applications, then you want a "full OS" such as any of the Unixes.
Personally, I've found the "loaded" kernels (such as VxWorks and QNX) to be of dwindling importance. When I do a system design I tend to end up with environments where I want a full Linux or BSD in order to have the latest in network stacks, or I want complete and total control of the processor. In the latter case I want the smallest kernel that will boot my state machine possible. I don't want efficient thread context switching, in those environments I don't want threads, just objects and state transitions.
You are missing an important distinction. The Desktop is not the OS.
Failure to make that distinction leads to systems that cannot be administered in any automated fashion because certain functions / controls are only available via the desktop. Apple is certainly guilty of providing skimpy documentation on how to administer your mac using only the command line.
If you don't view the Desktop as a GUI frontend to the OS the answers become very different. Once seperated from the OS, what does the Desktop do? It's a display system and it browses the file system.
And what does a Browser do?
Insisting that the Browser is inherently different from the Desktop amounts to saying that files not stored on your local system are not really files. It's one way to think of things, but it isn't necessarily the best way.
Now argumenets can be made that Browsing should be modular and distinct from the windowing system. But that should apply for local as well as remote files.
I write everything using state machines. They can avoid many conditionals, but not all.
Consider that any if expression considers factors which are:
A properly done state design eliminates by ifs that are based solely upon the event data. Seperate events should have been used, resulting in different actions.
An if that was based solely upon instance data that had values before the event can be eliminated. If based solely upon data known in advance, It could have been represented as a seperate state.
However any condition that is based both on instance and event data is a true conditional and cannot be eliminated from a state machine.
That is why transition guards and decision points are found on State Transition Diagrams.
Then you are not opposed to software patents. You are opposed to all forms of Intellectual Property rights.
Far too many patents have been granted for "inventions" that anyone would have figured out the second they tried to build a similar product.
That's the problem that needs to be addressed. Patents are supposed to encourage development of solutions that would not have otherwise been developed. What we have instead is severe "first post" problem that rewards squatters rights rather than true invention.
The biggest change I would make to patent law is to allow non-adversarial challenges to claims of being an innovation. Allow public comments to attack patents, without hiring lawyers, and the abusive patents won't survive for very long.
GPL is great for those that want to use it.
But some GPL-backers almost seem seek to forbid others from having retaining any form of proprietary rights on their inventions.
If the benefits of open-source collaboration are truly beneficial, then open-source projects will be able to compete with proprietary solutions without forcing proprietary systems to do without Intellectual Property protection.
What needs to be addressed is the rampant practice of "patenting" product ideas rather than truly innovative solutions.
In other words, open source software has to be protected from proprietary software "patenting" problems or "solutions" that were completely obvious. It does not need to have the right to steal innovations from proprietary software.
The amount of nuclear material is probably quite small. There is probably far more risk from any nuclear sub, or from an invading army that forgets to secure nuclear waste sites.
I never had a problem with incorporating web browser functionality with the desktop. The real issue was always the failure to seperate the desktop from the OS. Of course, with non-MS systems the OS, the desktop and browsers are all seperate, or at least potentially so.
Apple's only "unfair advantage" with Safari is that they are the Provider of the desktop. Obvously MAC users are more likely to like Apple's desktop, or to at least be fully familiar with it. Then there is the additional advantage of being a familiar brand name. So I believe the "secret message" here is that MS considers those factors alone to be an unbeatable combination. The implications is that it was all that they needed. (And for anyone who would buy that argument from them, I have some dotcom options to unload for a website selling swampland).