At UBS Warburg, Jack Francis, co-head of equity trading, said the sudden surge in price followed a 5-million-share block trade, considered to be a very large buy by Wall Street standards. "That was spurring stories of a potential takeover, which doesn't make any sense at all but did add fuel to the upside," said Francis. "The rumor doesn't hold a lot of weight, but in a market like this it gets people off the fence who are looking for any story that could generate alpha."
Anyway, Sun are currently valued at $12Bn, and have $5.5Bn sitting in the bank.
In the "low-end" of the market (systems costing under $100,000) Sun increased their revenue market share last year (2002 over 2001). Ie they grew faster than the industry average. Almost no Intel, Windows or Linux based systems are sold for more than $100,000.
So if Sun was being hurt by Linux (or x86 based systems in general) why did their market share increase?
It wasn't anything to do with the LX50 (dual P3 Solaris x86 / Linux) systems they launched late last year - they only shipped a bit over $1m worth by the end of the year.
my personal reading the the remarks was that Sun is now thinking of using Opterons instead of Xeons for future products. Given the product choice and testing phases Sun normally goes through, I wouldn't expect something for some time. Like a year at least. Especially since Sun are generally expected to announce 1U and 2U Xeon based systems in 3 months time...
btw, how come a Sun "rumour" story gets posted twice, but a product launch doesn't even get a mention? Anyone want a dual-processor 1U UltraSPARC system, with 4 1Gbit ethernet ports, advanced remote monitoring, dual SCSI and other goodies starting at $3000?
Why? It's smaller than most code, but why does that inherantly benefit Java?
Once the JIT kicks in, it's not Java vs C++ anymore, it's the JVM optimizer vs the GCC one.
That's the whole point. Unless you only care about programs where the entire execution time is a few seconds, the JVM optimisation time isn't going to be much of an issue.
However, the FFT benchmark is a case where the additional information available to the JIT optimizer allows it to outperform native code.
I compiled specifically for the machine I was running on. I tried everything I could to make it faster than Java. For Java VMs, being able to get "additional information" is what always happens. It's not specific to the benchmark.
The whole benchmark is so small, it probably even fits in cache, and doesn't really stress any of the performance pitfalls of the language itself.
The code is 10KB file with a number of critical functions. A good optimiser would have to do inlinging, loop unrolling as well as a lot of data-flow optimisation. I ran it across a range of data sizes, and Java did better at bigger array sizes (until memory bandwidth was the limiting factor). You have it the wrong way around - the smaller the code/data, the more language specific issues show up.
Now, if you have a larger application, that doesn't consist of a single inner-loop, and meanders through a lot of varied code (ie. most real applications) then the performance story will be very different.
Unless your app's performance is dependant on I/O, OS calls or strings, making the application bigger is not going to make things very different. Actually, it can give JVMs a number of extra advantages due to the super-inlining capabilities available to run-time generated code.
At that point, Java's performance faults (excessive bookkeeping overhead, object allocation/deallocation, overhead from the JVM, etc) come much more into play.
I don't know what you mean by "bookkeeping overhead" but C code has to allocate/deallocate memory too, and has problems like memory fragmentation. How things compare with a garbage collector depends on the code, system, JVM etc, but modern JVMs can handle 10s of gigabytes of data in the heap. Simply to say that GC is slow is simplistic. Unless you have code that only runs for a few seconds, "overhead from the JVM" (if by that you mean the optimiser) isn't going to be a problem.
I'm not saying there's not areas where Java is at a disadvantage (I've listed some in this post). In some areas, it's going to remain inherant, but in others, JVMs are becoming advanced enough that issues like run-time optimisation can be a distinct advantage. Anyway, as far as I'm concerned, I have no problems with Java performance for anything I've done, including GUI code.
These days when writing highly optimised web-server code in Java, I have to get a super-accurate timer since Java's standard timer is only accurate to one millisecond, and that's too coarse grained to tell how much different various optimised I add make. This is where all the HTML is dynamically generated for each request btw.
I've just been testing with a FFT benchmark I have, where I have both a Java version and a C version. Using GCC 3.2 on Linux, I've yet to be able to build a faster binary than what Sun's 1.4.2 beta JVM can do. IBM's JVMs are generally best at this type of benchmark, though Sun's been catching up fast, quite possibly passed them.
Even with CPU specific optimisations, advanced compiler options etc, the Java version is 30-80% faster than GCC's binary. (this is on both AMD and Intel CPUs) To get anything faster, you'd have to pay for it.
I also do server side programming, and I don't see why so many Linux users complain about Java's performance, while using/promoting Perl and PHP. If you want a high performance, responsive site, Java completely blows Perl and PHP away. I've only used JSP and servlets so far but they're all most web sites need anyway.
If you need performance for persistant data, this "new" system doesn't seem to be much different at all to what you can do today. Using JDO (Java Data Objects) with a file-system backend would be about identical, though easier to use and have more features.
Of course, you can always write your own persistance layer. I've done this a few times - very easy in Java. Map a row in the DB to an object, and cache the object in memory. If need to fetch that data again, check the cache first. When doing a write, write to the DB and update/flush your cache as necessary.
That's just the basics - what's most optimal depends on how your data is accessed and changed (and also your programming language and capability as a programmer). Java has nice really nice stuff for caching built-in, like SoftReference wrapper objects, and of course threading and shared memory that you can use in production.
I'm currently working on a super optimised threaded message board system. Almost all pages (data fetch/change + HTML generation) complete in about 0.001s.
From Q&A section: Q. Is OpenOffice.org 1.0 100% Microsoft Office file compatible? A. As Microsoft rarely publish their file specifications, no-one can answer that question. However, there are plenty of users who regularly edit and exchange documents, spreadsheets, etc with Microsoft Office users without any problems. Indeed, some users claim they've seen bigger compatibility problems moving between versions of Microsoft's own products.
Q. I've just saved a file from Microsoft Office in OpenOffice.org format, and it's much smaller - yet it hasn't lost anything? A. Good, isn't it?
Q. Has this suite got that annoying paperclip? A. No. Never has, never will. No. No!
With Amdahl checking out of the mainframe business it seems IBM has decided to raise mainframe prices significantly - it's actually charged more for the same performance in 2001 than in 2000! This is why IBM's mainframe revenues increased by a fair bit between 2000 and 2001 (while it's PC and Unix revenue dropped). Mainframe revenue accounts for about half of IBM's total server revenue...
The reality looks much darker instead. The CLR is not truly language-neutral, and it will ostensibly favor languages that look a lot like C#. Those not in this group will be severely bastardized, producing dialects which are really "C# with another syntax"; look at ISE's Eiffel# (or even Microsoft's own VB.NET and J#) for great examples. Programmers' choice will be limited to superficial features: whether to delimit their blocks with curly braces, Begin/End or parentheses. It's also worth notice that the CTS/CTS do not allow use of the full set of CLR features; for example, unsigned integers are supported by the CLR but not considered language-neutral, simply because many languages share Java's abomination for the signed/unsigned duality (this includes Microsoft's own VB) and there's no good solution for this issue.
-cut-
Playing with the.NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit.
UltraSPARC-IIIi will have a bit of async logic
on
Clockless Chips
·
· Score: 5, Interesting
Would we have had this if the software package was from Sun? Well, Sun might have blamed IBM, IBM might have blamed Sun and we'd be left with something which doesn't work. We've been lucky in that IBM want this to work to secure future business, and that is the carrot you can use to 'bribe' vendors to fix bugs.
Yeah, this is basically why Sun and Oracle have a
special support thing - basically Sun will support
both it's stuff and Oracle's (and Veritas too if
you're using that) with just one number to call
for all of it. "One throat to choke" as Scott
McNealy calls it.
However, I guess DB2 on Sun hardware is too small
to do the same thing... (they'll push you to
migrate to Oracle instead I guess)
They basically consider that Microsoft's continued
screwing of their customers (mostly contracts, but
they forgot to mention prices) is driving people
away. Also that many large (government) groups
around the world are considering similar stuff.
btw, the DoD are basically paying $0 for this -
they already have a support contract with Sun
to cover support. Good for US tax-payers eh.
Still hanging there pretty well though, I must
say. For some features (particularly the
dynamic reconfiguartion stuff), some of Sun's
major competitors are only just starting to
catchup/surpass. Bit late though - Sun's next
gen replacement is coming soon: more CPUs, more
and faster memory, better scalability, more
flexibility, better uptime, more features in
general and massive scalability - their new
top-end clustering stuff apparantly maxes out
at something like 18,000 CPUs (about 200
boxes) using the nice little 1TByte/s+ fiber
optic link.... Wish they'd hurry up and announce
it soon so we can see the full details, *sigh*
Part of the reason why some of the big server
types mentioned above want Linux is because it
already has a large mindshare and installed base. (a lot bigger than BSD and Hurd anyway)
These guys already have their own Unix OSs with
the high-end features that they want to see in
Linux, and they aren't going to be dropping their
current commercial Unix OSs quickly - that'd
annoy a *lot* of their customers, many of which
would then go straight to Sun, which is the last
thing they want.
Though there will be many different reasons and
objectives etc, I think the higher ups will want
the mindshare particularly...
SunWorld recently did an article on Sola ris 's journaling fs. They did a "pull the plug
test" too on with and without journaling on.
They also found that with journaling on the
file-system was quite a bit faster. (I've done
some testing myself, and found some things to
be about 10x faster...)
Re:Sun already pretty strong on the lowish-end, bu
on
Sun Buys Cobalt
·
· Score: 2
This may sound kind of way out there, but here goes: Why aren't there UltraSPARC chipsets for laptops?
US2e would be pretty ideal for laptops - it has
most of the chipset on die already (the "northbridge"). Power efficient too. Demand is
another matter...
I'm sitting here trying to think of one core competency of SGI's that Sun lacks, and can't source elsewhere. I'm drawing a
blank.
I'd have to agree.
SGI is going down.
Very much looks like it, unfortunately. However,
SGI pretty much have nobody to blame but
themselves. Sun's upcoming UltraSPARC-III based
workstations and servers, and their new super
graphics stuff is going to make life even harder
for SGI. (see New York event next Wednesday...)
Sun is just moving up a gear...
on
Sun Buys Cobalt
·
· Score: 4
Sun has unfortunately missed out on the whole low-end server game over the last few years, most likely because of their focus on Solaris and other "big iron" type products.
Erm, Sun have made about $1-3Bn/year on the low
end for the last several years. Their whole
Netra range is embedded/low-end. Their 1U Netra t1
launched last year has been a big success etc. Their low-end sales have been very strong recently - growing 60-80% in the last year.
Whilst they had recognised the potential for webservers, they seem to
have totally missed out on the idea that people would want to run them from home, and this is why Linux has taken off - it
may not be as good as Solaris, but it runs on your home PC.
Sun have always sold to business, not to the
public. (while some people do buy them for private/personal use, Sun certainly aren't in
the home computer business)
Now they're trying to get back into the low-end market through buy-outs rather than repositioning, because they're just
not flexible enough to do so - just look at Java for an example of Sun's cluelessness when it comes to the market. Buying
Cobalt may given them a portion of the market, but it will hardly path the way for them to gain any appreciable amount of
market share.
Sun started serious development, both hardware
and software for the embedded and low-end
server market several years ago. They already
have a strong presence in the "soft switches"
networking market and so on. The embedded/appliance style server market is just
taking off, and have a strong reputating in
the market, so it seems rather silly to write
them off.
Btw, most Java developers seem to me to be
pretty happy with the Java licencing situation.
You also don't seem to realise that Sun have
relaxed the license fairly recently too - JCP
2.0, for example...
To be honest, I don't really see much of a future for Sun. All of their recent moves seem to be those of desparation - giving
away Solaris, trying to keep Java proprietary and now buying Cobalt. Between Microsoft and Linux, they're fast becoming
a non-entity in the computing world.
Making Solaris 'free' has certainly been a sucess - especially on x86/Intel - about 200-300,000
installs in since it was released. That's more
than on SPARC...
Sun are growing faster than Microsoft, IBM, HP,
Dell, Compaq, Intel. They're now the biggest
server company (revenue wise) I think, and
that's just before they're about to completely
revamp their entire product line... (UltraSPARC-III finally coming next week.)
Sun already pretty strong on the lowish-end, but..
on
Sun Buys Cobalt
·
· Score: 3
In the last quarter, Sun sold about 100,000
servers total. Not bad going - that's PC
volumes.
The embedded server market is really taking off,
and Sun have been developing several things in
this area for many years. I remember reading
last week that they're expected to announce
quite a few embedded/applicance server things
in the coming months, and I guess this is one of
them.
Here's an interesting quote from the PR:
``Today we're acquiring Cobalt to establish ourselves in low-end server appliances and immediately jump into the marketplace with a proven,
world class product offering. This move is similar to our entry into the high-end server arena, which we did through our acquisition of Starfire
server technology from Cray. Just as that product line has become one of our most successful product lines to date, we think the demand for
these high-volume, turnkey devices will explode in the next couple of years. Cobalt is our bet for the future,'' said Ed Zander, President and Chief
Operating Officer, Sun Microsystems, Inc.
Only a week ago Sun announced the UltraSPARC-IIe - UltraSPARC-II for
low-end embedded applications. It has 256Kb on-die
L2, and pretty much the whole chipset on-die
too and can use PC100 SDRAM, apparantly. The
400MHz part is $145 in volume and the 500MHz
part is $225 in volume. They're pretty power
efficient too - 8W max for 400, 13W max for 500.
On interesting thing about Sun's involvement
to date with help Linux and the "open source
community" is that it's beeen more about helping
with software, rather than Sun trying to sell
Linux boxes. (Sun aren't likely to sell SPARC,
or other, boxes with Linux pre-installed for
some time - they're certainly not planning to
at the moment)
I was thinking that it would be unlikely to be a particularly x86 problem, because I know buffer overflows are also a problem on other CPUs and OSs even ones that are supposed to be secure.
Slashdot Mirror
Gosling likes idea of open source Java
At UBS Warburg, Jack Francis, co-head of equity trading, said the sudden surge in price followed a 5-million-share block trade, considered to be a very large buy by Wall Street standards. "That was spurring stories of a potential takeover, which doesn't make any sense at all but did add fuel to the upside," said Francis. "The rumor doesn't hold a lot of weight, but in a market like this it gets people off the fence who are looking for any story that could generate alpha."
Anyway, Sun are currently valued at $12Bn, and have $5.5Bn sitting in the bank.
In the "low-end" of the market (systems costing under $100,000) Sun increased their revenue market share last year (2002 over 2001). Ie they grew faster than the industry average. Almost no Intel, Windows or Linux based systems are sold for more than $100,000.
So if Sun was being hurt by Linux (or x86 based systems in general) why did their market share increase?
It wasn't anything to do with the LX50 (dual P3 Solaris x86 / Linux) systems they launched late last year - they only shipped a bit over $1m worth by the end of the year.
my personal reading the the remarks was that Sun is now thinking of using Opterons instead of Xeons for future products. Given the product choice and testing phases Sun normally goes through, I wouldn't expect something for some time. Like a year at least. Especially since Sun are generally expected to announce 1U and 2U Xeon based systems in 3 months time...
btw, how come a Sun "rumour" story gets posted twice, but a product launch doesn't even get a mention? Anyone want a dual-processor 1U UltraSPARC system, with 4 1Gbit ethernet ports, advanced remote monitoring, dual SCSI and other goodies starting at $3000?
Here's a list of all the new products Sun released on Tuesday
The FFT benchmark is a very specific case.
Why? It's smaller than most code, but why does that inherantly benefit Java?
Once the JIT kicks in, it's not Java vs C++ anymore, it's the JVM optimizer vs the GCC one.
That's the whole point. Unless you only care about programs where the entire execution time is a few seconds, the JVM optimisation time isn't going to be much of an issue.
However, the FFT benchmark is a case where the additional information available to the JIT optimizer allows it to outperform native code.
I compiled specifically for the machine I was running on. I tried everything I could to make it faster than Java. For Java VMs, being able to get "additional information" is what always happens. It's not specific to the benchmark.
The whole benchmark is so small, it probably even fits in cache, and doesn't really stress any of the performance pitfalls of the language itself.
The code is 10KB file with a number of critical functions. A good optimiser would have to do inlinging, loop unrolling as well as a lot of data-flow optimisation. I ran it across a range of data sizes, and Java did better at bigger array sizes (until memory bandwidth was the limiting factor). You have it the wrong way around - the smaller the code/data, the more language specific issues show up.
Now, if you have a larger application, that doesn't consist of a single inner-loop, and meanders through a lot of varied code (ie. most real applications) then the performance story will be very different.
Unless your app's performance is dependant on I/O, OS calls or strings, making the application bigger is not going to make things very different. Actually, it can give JVMs a number of extra advantages due to the super-inlining capabilities available to run-time generated code.
At that point, Java's performance faults (excessive bookkeeping overhead, object allocation/deallocation, overhead from the JVM, etc) come much more into play.
I don't know what you mean by "bookkeeping overhead" but C code has to allocate/deallocate memory too, and has problems like memory fragmentation. How things compare with a garbage collector depends on the code, system, JVM etc, but modern JVMs can handle 10s of gigabytes of data in the heap. Simply to say that GC is slow is simplistic. Unless you have code that only runs for a few seconds, "overhead from the JVM" (if by that you mean the optimiser) isn't going to be a problem.
I'm not saying there's not areas where Java is at a disadvantage (I've listed some in this post). In some areas, it's going to remain inherant, but in others, JVMs are becoming advanced enough that issues like run-time optimisation can be a distinct advantage. Anyway, as far as I'm concerned, I have no problems with Java performance for anything I've done, including GUI code.
These days when writing highly optimised web-server code in Java, I have to get a super-accurate timer since Java's standard timer is only accurate to one millisecond, and that's too coarse grained to tell how much different various optimised I add make. This is where all the HTML is dynamically generated for each request btw.
I've just been testing with a FFT benchmark I have, where I have both a Java version and a C version. Using GCC 3.2 on Linux, I've yet to be able to build a faster binary than what Sun's 1.4.2 beta JVM can do. IBM's JVMs are generally best at this type of benchmark, though Sun's been catching up fast, quite possibly passed them.
Even with CPU specific optimisations, advanced compiler options etc, the Java version is 30-80% faster than GCC's binary. (this is on both AMD and Intel CPUs) To get anything faster, you'd have to pay for it.
I also do server side programming, and I don't see why so many Linux users complain about Java's performance, while using/promoting Perl and PHP. If you want a high performance, responsive site, Java completely blows Perl and PHP away. I've only used JSP and servlets so far but they're all most web sites need anyway.
If you need performance for persistant data, this "new" system doesn't seem to be much different at all to what you can do today. Using JDO (Java Data Objects) with a file-system backend would be about identical, though easier to use and have more features.
Of course, you can always write your own persistance layer. I've done this a few times - very easy in Java. Map a row in the DB to an object, and cache the object in memory. If need to fetch that data again, check the cache first. When doing a write, write to the DB and update/flush your cache as necessary.
That's just the basics - what's most optimal depends on how your data is accessed and changed (and also your programming language and capability as a programmer). Java has nice really nice stuff for caching built-in, like SoftReference wrapper objects, and of course threading and shared memory that you can use in production.
I'm currently working on a super optimised threaded message board system. Almost all pages (data fetch/change + HTML generation) complete in about 0.001s.
Check out the guy's presentation:
Jonathan Schwartz presentation
Page 23:
All software will move to one distribution, and three licensing models - Traditional, Predictable and Metered
So comparing what Sun plans to what Microsoft has already done is rubbish.
download
Screen shots
List of changes
Marketing flyer
From Q&A section:
Q. Is OpenOffice.org 1.0 100% Microsoft Office file compatible?
A. As Microsoft rarely publish their file specifications, no-one can answer that question. However, there are plenty of users who regularly edit and exchange documents, spreadsheets, etc with Microsoft Office users without any problems. Indeed, some users claim they've seen bigger compatibility problems moving between versions of Microsoft's own products.
Q. I've just saved a file from Microsoft Office in OpenOffice.org format, and it's much smaller - yet it hasn't lost anything?
A. Good, isn't it?
Q. Has this suite got that annoying paperclip?
A. No. Never has, never will. No. No!
Testimonials
Timeline
Credits
Direct link to the post as a stand-alone page.
Just a little FYI:
With Amdahl checking out of the mainframe business it seems IBM has decided to raise mainframe prices significantly - it's actually charged more for the same performance in 2001 than in 2000! This is why IBM's mainframe revenues increased by a fair bit between 2000 and 2001 (while it's PC and Unix revenue dropped). Mainframe revenue accounts for about half of IBM's total server revenue...
Good article on this appeared today:
.NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit.
One Runtime to Bind Them All
Some quotes:
The reality looks much darker instead. The CLR is not truly language-neutral, and it will ostensibly favor languages that look a lot like C#. Those not in this group will be severely bastardized, producing dialects which are really "C# with another syntax"; look at ISE's Eiffel# (or even Microsoft's own VB.NET and J#) for great examples. Programmers' choice will be limited to superficial features: whether to delimit their blocks with curly braces, Begin/End or parentheses. It's also worth notice that the CTS/CTS do not allow use of the full set of CLR features; for example, unsigned integers are supported by the CLR but not considered language-neutral, simply because many languages share Java's abomination for the signed/unsigned duality (this includes Microsoft's own VB) and there's no good solution for this issue.
-cut-
Playing with the
"How Sun swerved to avoid Rambus"
http://www.theregister.co.uk/content/3/22279.html
More details on the CPU:
http://www.theregister.co.uk/content/3/22274.html
Sun press release:
Extends UltraSPARC III Chip Family Tree--First Use of Sun-Developed Asynchronous Logic Design in Chip's Memory Interface
At Sun Labs:
feature article
async research home page
Would we have had this if the software package was from Sun? Well, Sun might have blamed IBM, IBM might have blamed Sun and we'd be left with something which doesn't work. We've been lucky in that IBM want this to work to secure future business, and that is the carrot you can use to 'bribe' vendors to fix bugs.
Yeah, this is basically why Sun and Oracle have a
special support thing - basically Sun will support
both it's stuff and Oracle's (and Veritas too if
you're using that) with just one number to call
for all of it. "One throat to choke" as Scott
McNealy calls it.
However, I guess DB2 on Sun hardware is too small
to do the same thing... (they'll push you to
migrate to Oracle instead I guess)
They basically consider that Microsoft's continued screwing of their customers (mostly contracts, but they forgot to mention prices) is driving people away. Also that many large (government) groups around the world are considering similar stuff.
btw, the DoD are basically paying $0 for this - they already have a support contract with Sun to cover support. Good for US tax-payers eh.
These guys already have their own Unix OSs with the high-end features that they want to see in Linux, and they aren't going to be dropping their current commercial Unix OSs quickly - that'd annoy a *lot* of their customers, many of which would then go straight to Sun, which is the last thing they want.
Though there will be many different reasons and objectives etc, I think the higher ups will want the mindshare particularly...
SunWorld recently did an article on Sola ris 's journaling fs. They did a "pull the plug test" too on with and without journaling on. They also found that with journaling on the file-system was quite a bit faster. (I've done some testing myself, and found some things to be about 10x faster...)
There is the UltraBook though, from Tadpole.
US2e would be pretty ideal for laptops - it has most of the chipset on die already (the "northbridge"). Power efficient too. Demand is another matter...
- I'm sitting here trying to think of one core competency of SGI's that Sun lacks, and can't source elsewhere. I'm drawing a
blank.
I'd have to agree.- SGI is going down.
Very much looks like it, unfortunately. However, SGI pretty much have nobody to blame but themselves. Sun's upcoming UltraSPARC-III based workstations and servers, and their new super graphics stuff is going to make life even harder for SGI. (see New York event next Wednesday...)- Sun has unfortunately missed out on the whole low-end server game over the last few years, most likely because of their focus on Solaris and other "big iron" type products.
Erm, Sun have made about $1-3Bn/year on the low end for the last several years. Their whole Netra range is embedded/low-end. Their 1U Netra t1 launched last year has been a big success etc. Their low-end sales have been very strong recently - growing 60-80% in the last year.- Whilst they had recognised the potential for webservers, they seem to
have totally missed out on the idea that people would want to run them from home, and this is why Linux has taken off - it
may not be as good as Solaris, but it runs on your home PC.
Sun have always sold to business, not to the public. (while some people do buy them for private/personal use, Sun certainly aren't in the home computer business)- Now they're trying to get back into the low-end market through buy-outs rather than repositioning, because they're just
not flexible enough to do so - just look at Java for an example of Sun's cluelessness when it comes to the market. Buying
Cobalt may given them a portion of the market, but it will hardly path the way for them to gain any appreciable amount of
market share.
Sun started serious development, both hardware and software for the embedded and low-end server market several years ago. They already have a strong presence in the "soft switches" networking market and so on. The embedded/appliance style server market is just taking off, and have a strong reputating in the market, so it seems rather silly to write them off.Btw, most Java developers seem to me to be pretty happy with the Java licencing situation. You also don't seem to realise that Sun have relaxed the license fairly recently too - JCP 2.0, for example...
- To be honest, I don't really see much of a future for Sun. All of their recent moves seem to be those of desparation - giving
away Solaris, trying to keep Java proprietary and now buying Cobalt. Between Microsoft and Linux, they're fast becoming
a non-entity in the computing world.
Making Solaris 'free' has certainly been a sucess - especially on x86/Intel - about 200-300,000 installs in since it was released. That's more than on SPARC...Sun are growing faster than Microsoft, IBM, HP, Dell, Compaq, Intel. They're now the biggest server company (revenue wise) I think, and that's just before they're about to completely revamp their entire product line... (UltraSPARC-III finally coming next week.)
The embedded server market is really taking off, and Sun have been developing several things in this area for many years. I remember reading last week that they're expected to announce quite a few embedded/applicance server things in the coming months, and I guess this is one of them.
Here's an interesting quote from the PR:
- ``Today we're acquiring Cobalt to establish ourselves in low-end server appliances and immediately jump into the marketplace with a proven,
world class product offering. This move is similar to our entry into the high-end server arena, which we did through our acquisition of Starfire
server technology from Cray. Just as that product line has become one of our most successful product lines to date, we think the demand for
these high-volume, turnkey devices will explode in the next couple of years. Cobalt is our bet for the future,'' said Ed Zander, President and Chief
Operating Officer, Sun Microsystems, Inc.
Only a week ago Sun announced the UltraSPARC-IIe - UltraSPARC-II for low-end embedded applications. It has 256Kb on-die L2, and pretty much the whole chipset on-die too and can use PC100 SDRAM, apparantly. The 400MHz part is $145 in volume and the 500MHz part is $225 in volume. They're pretty power efficient too - 8W max for 400, 13W max for 500.It has quite a bit of analysis and history.
On interesting thing about Sun's involvement to date with help Linux and the "open source community" is that it's beeen more about helping with software, rather than Sun trying to sell Linux boxes. (Sun aren't likely to sell SPARC, or other, boxes with Linux pre-installed for some time - they're certainly not planning to at the moment)
http://www.sun.com/xml/
download page
Thanks for that.