The problem is that Microsoft is again leveraging it's monopoly advantage in the desktop market to muscle in on other markets that it does not yet own.
By putting it's products such as.NET as part of the default desktop (in which it has a proven monopoly) it gives other products (i.e Java) no opportunity to compete. Sure you can go and download Java, but this in itself is forced competitive barrier only possible because of Microsoft's desktop monopoly. The problem lies therein.
YOU CANNOT USE YOUR MONOPOLY POWER IN ONE MARKET TO CREATE COMPETITIVE ADVANTAGE IN ANOTHER.
Microsoft has continued to ship a broken implementation of Java 1.1.8 for going on 5 years now, while continually updating it's own OLE, COM,.NET.
It has done this purposefully, to fragment the Java market and confuse prosective users of Java. This is a bit like shipping only a Visual C 1.0 runtime - when the latest version is say 6.0 - even though you had a contract (that you broke) to ship it.
Believe it or not the Sherman Antitrust Act is perhaps the most free market ideal. In it is enshrined the concept of a level playing field where consumers benefit from proper market economics, innovation and lower prices. The slippery slope is product dumpin, standover tactics and stifled innovation.
Once apon a time a level playing field was what America was all about.
Also, "porting" and "refactoring" aren't necessary. Just recompile.
CFLAGS="-m64". What a rare insight.
Ok breathe deeply and concentrate.
Just because you compile this with a 64-bit compiler does not make it a 64-bit OPTIMIZED, REFACTORED application. Get this straight. It makes a 64-bit CROSS COMPILE of the 32-bit applciation you had before.
This is why AMD is doing this:
http://www.amdzone.com/releaseview.cfm?ReleaseID=1 035
And linux is continuing to do this:
http://216.239.51.100/search?q=cache:2Sh4LRuHKFEC: www.gnumonks.org/ftp/pub/congress-talks/ols1999/ia 64-slides.pdf+porting+linux+64&hl=en&ie=UT F-8
Even though I can already do this:
CFLAGS="-m64"
to this:
http://www.apache.org
Clear? Clear.
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 1
Agreed. but it's more than making your code 64-bit clean.
A naive port simply carries source code over, re-compiles and re-links it as necessary, and uses the executables that are verbatim translations of their 32-bit counterparts. This should, in general, give correct functionality.
Unless you optimize to take full advantage of features that the new architecture has available like parallel instructions and introspection, your performance can actually be worse.
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 1
If I buy any architecture in the future, by Moore's Law and the scale economies of the chip market, it's going offer better price/performance. This would be true for a 32-bit architecture or 64-bit or n-bit.
So what's your point?
Until consumer development shops start refactoring and releasing genuine 64-bit apps rather than just porting them (as I described), the benefits of 64-bit for the consumer will be negligble.
32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 4, Informative
No real benefit will come until geniune 64-bit apps hit the consumer market. This will be a steep learning curve for most developers who have only ever know 16 or 32-bit programming.
The problems to be hurdled are:
1) Reliance on the fact that size of pointer is equal to size of int.
2) Reliance on a particular byte order in the machine word.
3) Using type long and presuming that it always has the same size as int.
4) Alignment of stack variables.
5) Different alignment rules in structures and classes.
6) Pointer arithmetic.
A lot of engineering (and developer re-education) work also needs to be put into not only these issues, but also designing the application so that it is actually getting the most out of each clock cycle.
The AOL-Sun-Netscape alliance and the other charter members definately have the ability to push Liberty, but perhaps not the will.
If they wanted to AOL, Netscape, Mastercard, Visa and American Express could deliver a *staggering* amount of particpants. This would dwarf the several million Microsoft passport holders overnight.
I think that the main problem here with Sun's technical leadership is that it's too busy trying to work out what it does for a business to worry about taking on Microsoft in yet another arena.
Another reason is that the when you're a holding a hammer, everything looks like a nail.
Sun sees Liberty as a battle with Microsoft, Novell sees it as glorified LDAP server, while the credit card and mobile phone companies see it as a targeted advertsing and aggregation tool.
The conflict is being caused by each charter member having a different vision of what Liberty actually *is*.
Slashdot Mirror
Go fuck yourself.
The problem is that Microsoft is again leveraging it's monopoly advantage in the desktop market to muscle in on other markets that it does not yet own.
.NET as part of the default desktop (in which it has a proven monopoly) it gives other products (i.e Java) no opportunity to compete. Sure you can go and download Java, but this in itself is forced competitive barrier only possible because of Microsoft's desktop monopoly. The problem lies therein.
.NET.
By putting it's products such as
YOU CANNOT USE YOUR MONOPOLY POWER IN ONE MARKET TO CREATE COMPETITIVE ADVANTAGE IN ANOTHER.
Microsoft has continued to ship a broken implementation of Java 1.1.8 for going on 5 years now, while continually updating it's own OLE, COM,
It has done this purposefully, to fragment the Java market and confuse prosective users of Java. This is a bit like shipping only a Visual C 1.0 runtime - when the latest version is say 6.0 - even though you had a contract (that you broke) to ship it.
Believe it or not the Sherman Antitrust Act is perhaps the most free market ideal. In it is enshrined the concept of a level playing field where consumers benefit from proper market economics, innovation and lower prices. The slippery slope is product dumpin, standover tactics and stifled innovation.
Once apon a time a level playing field was what America was all about.
Just my 2c.
Acutally Mr Anonymous Smartass, I already have:
r c. rpm
;)
http://www.gurulabs.com/files/xmms-1.2.7-13.p.s
Your undying thanks are not necessary, just a long drivelling apology will do
MP3 Licence costs USD 60k even BEOS could afford it.. Redhat can't ?
I have source NVIDIA GLX and kernel tarballs here.
Why don't you check your facts before posting or at least post to comp.os.windows or something?
Also, "porting" and "refactoring" aren't necessary. Just recompile. CFLAGS="-m64". What a rare insight. Ok breathe deeply and concentrate. Just because you compile this with a 64-bit compiler does not make it a 64-bit OPTIMIZED, REFACTORED application. Get this straight. It makes a 64-bit CROSS COMPILE of the 32-bit applciation you had before. This is why AMD is doing this: http://www.amdzone.com/releaseview.cfm?ReleaseID=1 035
And linux is continuing to do this:
http://216.239.51.100/search?q=cache:2Sh4LRuHKFEC: www.gnumonks.org/ftp/pub/congress-talks/ols1999/ia 64-slides.pdf+porting+linux+64&hl=en&ie=UT F-8
Even though I can already do this:
CFLAGS="-m64"
to this:
http://www.apache.org
Clear? Clear.
Agreed. but it's more than making your code 64-bit clean.
A naive port simply carries source code over, re-compiles and re-links it as necessary, and uses the executables that are verbatim translations of their 32-bit counterparts. This should, in general, give correct functionality.
Unless you optimize to take full advantage of features that the new architecture has available like parallel instructions and introspection, your performance can actually be worse.
If I buy any architecture in the future, by Moore's Law and the scale economies of the chip market, it's going offer better price/performance. This would be true for a 32-bit architecture or 64-bit or n-bit.
So what's your point?
Until consumer development shops start refactoring and releasing genuine 64-bit apps rather than just porting them (as I described), the benefits of 64-bit for the consumer will be negligble.
No real benefit will come until geniune 64-bit apps hit the consumer market. This will be a steep learning curve for most developers who have only ever know 16 or 32-bit programming.
The problems to be hurdled are:
1) Reliance on the fact that size of pointer is equal to size of int.
2) Reliance on a particular byte order in the machine word.
3) Using type long and presuming that it always has the same size as int.
4) Alignment of stack variables.
5) Different alignment rules in structures and classes.
6) Pointer arithmetic.
A lot of engineering (and developer re-education) work also needs to be put into not only these issues, but also designing the application so that it is actually getting the most out of each clock cycle.
The AOL-Sun-Netscape alliance and the other charter members definately have the ability to push Liberty, but perhaps not the will.
If they wanted to AOL, Netscape, Mastercard, Visa and American Express could deliver a *staggering* amount of particpants. This would dwarf the several million Microsoft passport holders overnight.
I think that the main problem here with Sun's technical leadership is that it's too busy trying to work out what it does for a business to worry about taking on Microsoft in yet another arena.
Another reason is that the when you're a holding a hammer, everything looks like a nail.
Sun sees Liberty as a battle with Microsoft, Novell sees it as glorified LDAP server, while the credit card and mobile phone companies see it as a targeted advertsing and aggregation tool.
The conflict is being caused by each charter member having a different vision of what Liberty actually *is*.
I have hundreds to spare..
Is this to provide a amusement to future anthropologists and social historians?