Sun Chief Calls Out IBM, Demands Compatibility 419
downbad writes "Sun's President, Jonathan Schwartz, yesterday published an Open Letter to the CEO of IBM, Sam Palmisano, in which he alluded to "behavior reminiscent of an IBM history many CIOs would like to forget" - a reference to Sun's frustration that IBM isn't supporting Solaris 10 with WebSphere, DB2, Tivoli, Rational and MQSeries products. In his "Dear Sam" letter - circulated via his blog - Schwartz refers first to the "long history of partnering" between Sun and IBM, and claims Sun customers have made repeated calls to IBM about having the choice to run IBM products on Solaris 10." *cough* Kettle, meet Pot.
Sun trying to divide and conquor open source? (Score:1, Interesting)
No, Jonathan, IBM won't switch from Linux to Solaris just because you got the OSI to look at your license. Perhaps make it GPL compatable and try the FSF and see if it'll pass there - then I at least might listen.
I hope IBM's response is "make Solaris GPL compatable and we'll support it too, once we merge it with Linux"
Isn't that a bit... (Score:3, Interesting)
Slightly Off Topic (Score:5, Interesting)
If WSAD were ever ported to OS X, my boss would be placing a nice order for xServes and powermacs on the Apple website.
IBM is a "service" company, right? (Score:4, Interesting)
Of course, IBM still has strong roots as a "hardware" company. What's IBM's incentive to rewrite their software (little profit) on Sun's hardware (no profit)? Not a whole lot of incentive there.
Re:Slightly Off Topic (Score:3, Interesting)
In 1993, IBM provided the compilers for Apple's new hardware. For a while, Apple Workgroup Servers were merely RS/6000s running AIX with an Apple logo on the front panel.
Rumor has it, at one point IBM was going to port their XL C++ (C Set ++ by then) compiler to Mac OS. (That was, of course, way before OS X, so it would be a massive user interface and library effort--the actual code gen for PowerPC 604 was already complete, for the RS/6000s.)
So, yeah, IBM and Apple have been surprisingly close for a while now. With BSD and X11, I don't know why they don't do a quick build of a lot of their apps--instantly add a new target market. Sure, Cocoa is nicer, but X11 is there and it works and you'll be done.
Of course, I do know from experience that IBM is very reluctant to do a "90%" solution--one that works for 90% of the target customers. They'll kill themselves trying to get that last 10% of function, and spend so much time at it that the 90% has gone to some other vendor, the market has changed, and now no-one cares.
Re:Well then let's see DTrace, ZFS, etc. on Linux (Score:3, Interesting)
Translation: (Score:4, Interesting)
Seriously, IBM will port their software if they can make more money selling the Solaris versions than it cost to port and support. That's it.
IBM may show largesse toward open source, but that's because they view it as strategic. Solaris isn't strategic for them, no matter how much Schwartz may wish it so.
Garg
Re:kettle, pot? (Score:2, Interesting)
Re:kettle, pot? (Score:2, Interesting)
Yes. Johnathon's "open letter" is one of the silliest, snarkiest, stupidest things I've seen in some time.
Oh, Johnathon, you're so clever with your "open letter" on your blog. Gimme a break. Your company is not doing well and hasn't been since the easy pickings of the dot-com years when everyone did well. You've been one of the sick men of the IT world for years. You finally managed to eke out a tiny profit, but your revenue continues to slide. Analysts are not impressed and while you were busy getting in your competitors' faces [sun.com] and thumping your chest, your stock dropped some more...I mean, I'm reading his blog and looking at SUNW's chart and thinking "are we reading the same Q4 release?" Maybe if you spent some time running it instead of talking shit to your competitors you'd have some ground to stand on.
Why hasn't IBM ported its products to Solaris 10? Perhaps because it isn't released yet. Perhaps because there's no demand. We run IBM tools (Tivoli, MQ, etc.) on Sun boxes and there is every reason to believe that they'll port their tools once they perceive a market. Hey, Johnathon, does N1 support anything other than Sun's blades yet? You lock-in dogs!
Johnathon Schwartz is acting like an overpaid NBA player whose game isn't all that good. If Wilt Chamberlain talks trash, it's one thing, but if it's some second-rate bencher who has no game, it just looks sad. Tell you what, Johnathon - how about not dissing IBM or HP [sun.com] until Sun's back on top?
Re:Stating the obvious... (Score:3, Interesting)
As far as I recall... (Score:2, Interesting)
Re:IBM is a "service" company, right? (Score:3, Interesting)
Re:Stating the obvious... (Score:3, Interesting)
Seriously, on Solaris, do NOT try to use the 'killall' command like you would in Linux. Especially if you're root. In fact, don't ever use it at all. I don't even know why it's there. I learned this the hard way, hopefully someone else will learn from my mistake.
Though I find the expectation that the Solaris tools be like Linux a little strange, given that SunOS/Solaris has existed before Linux.
Re:RDBMS's: Proprietary vs. Commercial (Score:3, Interesting)
> not be done on PostgreSQL (it could) but it would expensive as well.
Good point - a database performing 50,000 transactions a second isn't running on your grandmother's pc. But it wouldn't be correct to assume that all databases scale equally. This is where the greater tuning opportunities of db2 or oracle come into play:
- instead of just a single 8k page size, db2 has 4k,8k,16k, and 32k page sizes.
- db2 has much more flexible statistics gathering than either mysql or postgresql
- db2 has a far more robust & intelligent optimizer than any open source database
- db2/oracle/etc have query parallelism
- db2 in particular is very good at performing most database operations asynchronously: data writes are sent to a buffer pool by one agent, to a log buffer by another, from the log buffer to the log file by another, from the log buffer to actual storage by another, etc, etc.
- both mysql & postgresql have very primitive memory tuning capabilities: mysql can't share io buffers between innodb & mysql. Postgresql just doesn't have many options to manage sort memory, separation of memory buffers by tablespace, etc, etc.
But keep in mind - many of these weaknesses are also strengths: since the missing configurability is translated to simpler management for smaller & less-demanding databases.
> However, unless you have all the information in memory or unless the the data is spread across a
> large number of disk arrays, I don;t see how you can even get the information to process it in less
> than a second.
Ok, here's an exeample architecture using db2. Would work identically on informix, and probably Terradata. Oracle has similar capabilities, though a little different since they're shared-disk rather than shared-nothing for db2/informix/terradata.
Step 1: spread data across 10 2-way 64-bit AMD blades. Each blade has 8 gbytes of memory and a fibre connection to storage. You can expand this up to *hundreds* of blades (nodes) - and get almost linear performance improvement the entire time. You've now got a 20 CPU system for about 10% the price you'd pay for a Sun E10000 or HP Superdome. Since the data is spread across all nodes by hashkey - every query will get 20 CPUs processing it together - each on 1/10 (100 gbytes) of the original data.
Step 2: partition the data on each node by range or value via MDC. Say, by 'day' & 'department' - so that you've got (for example) 1000 days & 1000 departments. Now, each query will only tablescan the data within the blocks it needs: whether it needs to scan 5% or 75% it gets a linear performance improvement corresponding to the reduction of data.
Step 3: implement parallelism on each node. Now, this sample config only has 2 CPUs - so the opportunities aren't as great as they are on an 8-way. But a two-way will still usually cut your query time in half.
So, now a few examples:
1. query for 10 days of data for 1 department:
a. clustering cuts 100 gbytes on each node down to about 1 mbyte to scan on each node.
b. query parallelism cuts down scan on each node to about 500 kbytes
2. query for 100 days of data for 100 departments:
a. clustering cuts 100 gbytes on each node down to about 1 gbyte to scan on each node.
b. query parallelism cuts down scan on each node to about 500 mbytes
3. query for 365 days of data for all departments:
a. clustering cuts 100 gbytes on each node down to about 40 gbytes to scan on each node.
b. query parallelism cuts down scan on each node to about 20 gbytes
All three queries - whether very selective or not, all use the same facility for a linear performance improvement (unlike indexes). The last query is unlikely to complete in 1 second - but I'll bet it'll be fast nevertheless - especially since it'll probably end up with over 2
Re:What's the ideal FOSS database choice for (Score:3, Interesting)
I am assuming you mean www.craigslist.org.
Ok. Seems like you have a few issues:
1) Such a directory will have a lot of reads and only a few writes. The writes seem to mostly be inserts, with few updates.
2) I don't see anywhere on the web site where financial data is likely to be an issue.
The major benefits of MySQL include:
1) Easy to find developers who know it.
2) Would run adequately, given enough hardware.
The major benefits of PostgreSQL would include:
1) Better data analysis capabilities.
2) Very robust database manager with extensive capabilities and a strong emphasis on data integrity.
3) The ability to confidently integrate ecommerce and financial data into the same database architecture without worrying about rounding errors.
MySQL will work well enough. PostgreSQL will give you more. Under high load, PostgreSQL may outperform MySQL due to the fact that it has better caching. So if you get really busy PostgreSQL will scale better (traffic-wise).
PostgreSQL will also scale well data-wise. Each row can hold up to 2GB data, and each table can hold 64TB without partitioning. Affilias, who runs the
Affilias is currently bidding to take over the