Sun Offering Optimized AMP Stack On Solaris 135
tbray writes "This is your friendly local Sun corporate drone reporting that we're going to be building and optimizing and DTrace-ing and shipping and supporting the AMP part of LAMP (details here). I think that basically the whole tech industry, excepting Microsoft, is now at least partly in the AMP camp."
The job isn't finished yet, until all of...(NICE!) (Score:5, Interesting)
Excepting MS? (Score:1, Interesting)
dom
Postgres Migration (Score:4, Interesting)
I don't want to get into a holy war about the relative merits: we already use Postgres, we will not support two database systems, we are not switching from Postgres to MySQL. MySQL might be good for others, but not for us.
But we do get these LAMP apps that come bundled with MySQL. Usually they don't use any MySQL specific features that Postgres (and maybe moving some functions across the app/DB boundary) can't directly support. So I'd like to get a LAMP -> LAPP migrator that will automate the switch. Leaving optimizations for after the switch, to be performed by other (Postgres) tools or programmers/DBAs. The open source of these two DBs, and the open source of all these LAMP apps, should make migration between them accessible.
I'm sure there are lots of people like me. Where's the tool that makes the open source as good for migrating among these programs as creating them from scratch?
Re:Yawn.... (Score:4, Interesting)
Re:Yawn.... (Score:3, Interesting)
A while back there were some interesting comparisons of SQL performance on Darwin/Mac OS X versus Linux, under controlled conditions on similar hardware; it would be interesting to see a Sun-AMP versus LAMP comparison, done by some disinterested party, using the same versions of all the same software except for the OS, wherever possible. If Sun could outperform Linux, it would be intriguing
Re:Yawn.... (Score:3, Interesting)
Re:Yawn.... (Score:5, Interesting)
Ah, but remember -- Sun can sell you a machine which goes well beyond the whole 'similar hardware'.
If they can sell someone an optimized, supported, and enterprise-class piece of hardware which is basically turnkey, and can fill the job of being your web-facing front-end, there will be companies for whom this is a very good idea.
What Sun can sell you is the higher end for which there is no way you could build it with a commodity PC. Enterprise customers have enterprise hardware needs, and enterprise mindsets. Being "PHB Compatible" is a valuable thing in business, cause if things go to shit, you have someone who can come in and make things go again.
Sun isn't trying to get the hobbyist shop; they're targeting higher end companies with bigger budgets who want reliability.
If for nothing else than they're going to support the AMP stack, I have to commend Sun on this decision. This can only be good for those parts of the stack, and it won't really hurt Linux in any way -- this is complementary. This will have the effect of giving PHBs an option which uses Apache, MySQL, and PHP/PostgressSQL (whichever it is). I don't see this as being a 'lose' for the OSS people.
Why is Slashdot so pathologically opposed to someone buying a computer and operating system, even if it makes sense for their business goals?
Cheers
Re:Yawn.... (Score:3, Interesting)
Solaris is a pretty darn good product. And if Sun starts providing full time support for the "AMP" part of the stack, you can probably bet that bug fixes for Solaris won't be far behind those for Linux. And if Sun follows through and GPLv3's Solaris, things really start to get interesting...
Re:Yawn.... (Score:2, Interesting)
Dtrace (Score:3, Interesting)
On the high end, bottlenecks are something to really watch for and identify, and Dtrace is an excellent tool for that sort of activity. This will be very interesting to watch.
Also, if Solaris DOES go GPLv3, the immediate availability of a superior SAMP stack that is GPL could turn a lot of heads, and may even displace some LAMP systems quickly and painlessly.
Re:The "AMP Camp"??? (Score:3, Interesting)
Really - don't knock something for being good.
Re:Postgres Migration (Score:3, Interesting)
Sometimes, you end up having to have a different schema for the different databases because of optimizations that one supports and the other doesn't. For example, modeling trees in Oracle can be done with the CONNECT BY clause, which very few (any?) other databases have, so instead you choose whatever your database can deal with (there are many representations for trees; there's a whole book on the subject, actually: http://www.elsevier.com/wps/find/bookdescription.
Often you can choose something that works reasonably well on all the platforms you need to support, but if it ends up being a bottleneck (I've seen it happen more than once), you end up making different schemas and having to deal with all the headaches that come with it.