• dave (unregistered)

    I wish I had an E10K here - it's taking forever to compile.

  • Anonymous (unregistered)

    Wait - so the real WTF that the bank actually did a cost/benefit calculation and pulled emergency stop BEFORE spending the biggest part of the money?

  • Anon (unregistered)

    Exactly how big of a user load will one of those babies handle? And exactly how many staff did they expect to have using it such that they needed their own fully decked out server?

  • Justice (unregistered)

    The Real WTF(C) is that the bank was trying to roll their own version of a Bloomberg terminal as part of a website. Or perhaps I should say, The Real WTF is that seemingly every company felt it necessary to roll their own <thing> around that time.

    Also, we want Irish Girl back.

    captcha: letatio - sounds vaguely dirty.

  • (cs)

    Just imagine how fast those OpenGL screen savers would have run on those babies!

  • Edss (unregistered) in reply to Justice

    Agree on all points.

    Except captcha.

  • The Undroid (unregistered)

    Odd that you should not mention software. I'm betting that somewhere they were running Oracle EE on a bunch of processors at $40K/cpu before discounts.

  • (cs)

    Compare this to Google, which built a multi-billion dollar empire using cheap commodity hardware.

    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.

  • SomeCoder (unregistered) in reply to Anonymous
    Anonymous:
    Wait - so the real WTF that the bank actually did a cost/benefit calculation and pulled emergency stop BEFORE spending the biggest part of the money?

    The way I read it, it sounded like the bank bought all those servers (for $40,000,000) and THEN did the cost analysis, finding that nobody was interested.

    Or maybe it was Chris G.'s company that bought them and then the bank canceled. I couldn't quite tell but I got the impression that $40,000,000 was spent by somebody before they did the required analysis.

  • yEAH rIGHT (unregistered)

    ...and if you go to www.e10k.net, you can buy one of them at kentucky steakhouse !

  • (cs)

    I don't see why they needed to cancel the entire project. Just can Sun's participation in it. Instead of clusters of 64-processor server behemoths, they could just buy one reasonably high-powered server and start with that, scaling up if demand did grow.

    Or perhaps they realized that if only 100 people were interested, maybe it was dead from the start.

  • (cs)
    keeping the dot-com bubble invincible to this day.
    You misspelled "invisible".
  • Not Dorothy (unregistered) in reply to WhiskeyJack

    I have an urge to visit eBay and look at the old Unix kit

  • Steve H. (unregistered)

    Sounds to me like Sun was the company responsible for a lot of the WTF (though Chris G's company approved it and paid for it). Seriously, Sun was the one that recommended buying $36M of their equipment, said company was just following their recommendation.

    Can you sue someone for a grossly bad recommendation? I know I'd look into that option if I was out $36M

  • Erik (unregistered)

    This sort of excess is actually pretty tame by dot-com standards. During the dot-com boom, I worked for a company that started out as a CLEC, then started buying up ISPs. Then, they decided to become a data center company, and burned through a quarter of a billion (yes, with a b) dollars building data centers all over the country.

    I had the pleasure of traveling to several of these data centers, and saw nothing but giant expanses of empty floor, sometimes with one or two racks in a corner. Not surprisingly, the company tanked after about 3 years.

  • Mike Dimmick (unregistered)

    Over 90% of all systems are I/O-bound. There was probably a single SCSI disk hanging off the back of that lot.

    If you're not CPU-bound, adding CPU cores will not make your system go any faster. Even if the CPU meters seem to indicate that you are, you could well be memory-bound. Current CPU-monitoring techniques don't differentiate between CPU cycles computing a result, and CPU cycles wasted waiting for main memory to supply the next piece of data (or next instruction, in some cases). A table scan of a 4GB table, where the whole table is already buffered in RAM, will take quite a while and look like 100% CPU usage on the core that's executing the scan - but it won't be any quicker if you add more cores or bump the CPU speed because the CPU's just waiting for the memory, which won't respond any faster.

    (Exception: some databases might be able to do a parallel table scan if CPU cores are available, with each core attacking part of the data set.)

  • Anonymous (unregistered) in reply to yEAH rIGHT

    ... ok, that's one of the most perversely elegant spam link-farmish things I've seen.

  • (cs)

    Fortunately, he forgot the link.

  • Zygo (unregistered)

    The real WTF is that they let Sun round up by $4M. They should have insisted on at least a 5% discount just for the sheer volume.

  • NeoMojo (unregistered) in reply to Zygo

    And because they were paying in cash.

  • Anon (unregistered) in reply to gabba
    gabba:
    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.
    Sadly, no. Most new non-Apple, non-Verizon cellphones contain a useless J2ME implementation, which you do pay Sun for.

    So just like people complain about the "Microsoft tax" when buying new PCs, new cellphones get dinged the "Sun tax" to allow you to run crappy mini-Java applications that no one in their right mind would ever use.

    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

  • (cs)

    Is it just me that thinks Sun did a damn good job here? Keep in mind all the competence this club hired. If you are able to sell 18 servers worth $40m to such a project(team) you deserve a place in the hall of fame.

  • T604 (unregistered) in reply to gabba
    gabba:
    Compare this to Google, which built a multi-billion dollar empire using cheap commodity hardware.

    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.

    so trolling gets your comment modded up (or whatever it is that makes some comments more visible than others)

  • Some Business/IT Crossbreed (unregistered) in reply to gabba
    gabba:
    Compare this to Google, which built a multi-billion dollar empire using cheap commodity hardware.

    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.

    Still stuck on 20th century business models, eh? Well, I admit it was hard to give up my Commodore 64.

    Call me when you reach the 21st century.

  • Bruno (unregistered)

    Not really a WTF, they actually checked that the project was still viable and cut their losses. The company I work for at the moment would have done that after the web site had been delivered late and over budget.

    As for Sun's hardware such as the e10k, It's quite amazing kit. Yes it's more expensive than a cluster of commodity hardware but it is meant for a different purpose. In the case of Google, it doesn't matter if a small number of user transactions get aborted when one of the commodity hardware nodes in the cluster suddenly gives up the ghost: the user just has to reload the page and subsequent requests are re-routed. In the case of a bank, a single transaction that gets lost could be a financial transaction so they can't afford to lose it: they absolutely need it to complete. Hence why they favour large highly available SMP systems like the e10k. In this particular case, being a web site, they could theoretically have used a commodity hardware cluster but it made more sense to go for what they knew already and for which they probably already had in-house maintenance skills.

    Yes it looks like a huge waste of money but it could have been much, much worse. In hindsight, they should have done their market analysis better as they were already deeply in the red just with their marketting campaign. And in hindsight, Chris learnt that you never, ever, ever bet your business on a single juicy contract or customer, however good and bullet-proof it may look: always spread your risk, 10 small contracts/customers are safer than 1 big one.

  • Anon (unregistered) in reply to T604
    T604:
    gabba:
    Compare this to Google, which built a multi-billion dollar empire using cheap commodity hardware.

    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.

    so trolling gets your comment modded up (or whatever it is that makes some comments more visible than others)

    It's not trolling, it's just not realizing that Java has infested more devices than you might imagine.

    How do you propose to make money off a product that you give away for free? Even the "Enterprise" edition of Java is free.

    Well, the answer is simple: training and certification. Sun makes most of its money on J2SE and J2EE via training and certification programs.

    But that's not the complete answer. The complete answer is that Sun has managed to infest quite a bit of consumer hardware with Java implementations, which the consumer does have to pay for.

    Examples include cellphones (J2ME), Blu-ray players (it's a requirement!), various set-top cable boxes (supposedly - not in the US), and other devices that have no business running something as slow as Java.

    So, yes, Sun does manage to make money on Java. It's just not something that's easy to see, because no one ever thinks "oh, I'll go out a buy me some Java!" instead they get stuck paying more than they should have to for some device that happens to have a slow and crappy Java implementation.

  • (cs)

    Crazy.

    Hmm, I think I'll go out and buy me some Java!

  • BadReferenceGuy (unregistered)

    The real WTF is that they trusted a Sun consultant to tell them how much they should spend on Sun products, and let them know that money was no object. That would be like telling a salesman "I want to spend as much on this car as possible."

  • (cs)
    management canceled the entire project, sending nearly a floor of developers to the curb

    A "floor" of developers? Is that a new unit of measurement? How many developers in a floor?

  • TCombs (unregistered) in reply to yEAH rIGHT

    Sweet - nested WTF's!

  • Southern (unregistered)

    I wonder if I can run doom in one of those

  • (cs) in reply to Anon
    Anon:
    It's not trolling, it's just not realizing that Java has infested more devices than you might imagine.

    How do you propose to make money off a product that you give away for free? Even the "Enterprise" edition of Java is free.

    Well, the answer is simple: training and certification. Sun makes most of its money on J2SE and J2EE via training and certification programs.

    But that's not the complete answer. The complete answer is that Sun has managed to infest quite a bit of consumer hardware with Java implementations, which the consumer does have to pay for.

    Examples include cellphones (J2ME), Blu-ray players (it's a requirement!), various set-top cable boxes (supposedly - not in the US), and other devices that have no business running something as slow as Java.

    So, yes, Sun does manage to make money on Java. It's just not something that's easy to see, because no one ever thinks "oh, I'll go out a buy me some Java!" instead they get stuck paying more than they should have to for some device that happens to have a slow and crappy Java implementation.

    Quite right, but this just proves my point. The cellphone and other device manufacturers don't have to pay Sun to implement a Java runtime (they can use a free implementation); they do it just for "training and certification" and other silly reasons. Just like today's WTF; the bank didn't have to use the expensive hardware the Sun salesman shoveled at them; they could have used commodity hardware. But then that wouldn't have been as enterprisey, would it?

  • aaawww (unregistered) in reply to Anon
    Anon:
    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

    well, me thinks that some while ago the myth of slowness of java desktop applications was debunked...

    otho, i like to play the midp dweller roguelike

  • (cs) in reply to El_Heffe
    El_Heffe:
    A "floor" of developers? Is that a new unit of measurement? How many developers in a floor?

    It's one of those variable units of measurement...like the length of the king's forearm.

    1 floor of developers = from 20 (Parsippany, NJ) to 120 (mid-town Manhattan, NY)

    Maybe the OP can specify the value for this story.

  • esse (unregistered)

    I though the "Java is SLOW" went out of fashion back in 2000?

    Bad troll, keep up.

  • Anonymous (unregistered) in reply to Anon

    Well, we ran about 5,000 simultaneous connections on them. They performed pretty well, when they were sized right.

    That said, we replaced it with IBM kit that was 1/4th the size and performed much better.

    Now we're going to AMD which are another 1/4 the size, and even faster.

  • Anon (unregistered)

    What's a BCP?

  • (cs)

    I think they should have done several hardware scenarios. Locking on to just what Sun thought is TRWTF. Its not like it was the only option. And you don't need a 64 processor server just for developers to play with, I think 5 or 10 might have been plenty to expose any scalability problems.

  • GF (unregistered) in reply to Erik
    Erik:
    Then, they decided to become a data center company, and burned through a quarter of a billion (yes, with a b)
    I agree, much more dramatic than saying "250 million (yes with an m)"

    Captcha: jugis. Not gonna go there.

  • GF (unregistered) in reply to Anon
    Anon:
    gabba:
    So now you can understand why Sun is sitting on a mountain of cash despite essentially having no product. Well, except for Java. Well, so really no product.
    Sadly, no. Most new non-Apple, non-Verizon cellphones contain a useless J2ME implementation, which you do pay Sun for.

    So just like people complain about the "Microsoft tax" when buying new PCs, new cellphones get dinged the "Sun tax" to allow you to run crappy mini-Java applications that no one in their right mind would ever use.

    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

    Welcome to the 2000s. Have you even tried any java apps in the last five years, or are you just running off at the mouth based on a bad experience from a decade ago? All blackberry apps are Java (including the google maps implementation which gives real-time GPS-based positioning). The only performance issues I ever see are in poorly coded specific applications. As for the desktop - take a look at Netbeans, or Eclipse -- tools that are unmatched for capability, written in Java, with no discernable speed difference from native .

  • tego (unregistered) in reply to Anon
    Anon:
    What's a BCP?
    http://en.wikipedia.org/wiki/Business_continuity_planning at a guess.
  • Anon (unregistered) in reply to aaawww
    aaawww:
    Anon:
    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

    well, me thinks that some while ago the myth of slowness of java desktop applications was debunked...

    otho, i like to play the midp dweller roguelike

    When's the last time you used a Java desktop application? I use one daily, it's based on Eclipse, so any of the "it's just Swing" arguments can be chucked out the window because Eclipse uses SWT which actually uses native widgets.

    It's the slowest freaking thing I've ever used and it's even more hungry for memory than Firefox loading an AJAX web application. Once it finally gets loaded and running, it's fast enough for typing text.

    But every couple of minutes - FREEZE! It just stops. Best guess is that this is the Java garbage collector freezing the entire application for 10 seconds.

    Whenever it needs to load something (for example, to autocomplete some text) - FREEZE! The entire application stops for 10-20 seconds.

    Try and do anything more complicated than text editing, and you're in for even more slowdowns.

    So, no, Java being slow on the desktop is NOT A MYTH. If you've ever used a Java desktop application recently, you'd know that.

  • (cs) in reply to GF
    GF:
    Erik:
    Then, they decided to become a data center company, and burned through a quarter of a billion (yes, with a b)
    I agree, much more dramatic than saying "250 million (yes with an m)"

    Captcha: jugis. Not gonna go there.

    I was just noticing how people (esp. media) do that a lot. It is all from drama right? 1/4 billion seems bigger than 250 million? I don't see 3/4 billion as much though. maybe because 750 million is significantly large?

  • (cs) in reply to Southern
    Southern:
    I wonder if I can run doom in one of those

    Yes but not in Windows you couldn't. You would first have to exit to DOS.

  • (cs) in reply to esse
    esse:
    I though the "Java is SLOW" went out of fashion back in 2000?

    Bad troll, keep up.

    Except that Java is slow (on lower-end systems, anyway).

  • I walked the dinosaur (unregistered)

    Epic Fail!

  • (cs) in reply to esse
    esse:
    I though the "Java is SLOW" went out of fashion back in 2000?

    Bad troll, keep up.

    Exactly. Any poorly coded app can be slow, not just java apps. The idea of running j2me on your mobile phone is so that developers can write programs that will run on more than just one phone, theoretically withou a significant overhead of customizing their code for each single cellphone out there (and there are quite a few out there). But, please, continue telling us how SLOW java is and how our phones are INFESTED with java, especially when most of the slowness in phones comes from provider-specific firmware instead of using factory firmware (for example, my T-Mobile RAZR takes longer to access my contacts than my 8 year old Nokia shitbox did, despite not changing the number of contacts).

  • Anon (unregistered) in reply to Anon

    I work for a pretty large company, we handle about 10-15 million transactions a day (up to $45 million in sales an hour) and we run Active/Passive on E6900's with plenty of room to spare. (32 cores) The passive node isn't even fully loaded, it takes 2 of the boards from the Active node in a failover (terrible design, but management is CHEAP) Never had an issue though, every bit of each system is fully redundant

  • (cs) in reply to Anon
    Anon:
    aaawww:
    Anon:
    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

    well, me thinks that some while ago the myth of slowness of java desktop applications was debunked...

    otho, i like to play the midp dweller roguelike

    When's the last time you used a Java desktop application? I use one daily, it's based on Eclipse, so any of the "it's just Swing" arguments can be chucked out the window because Eclipse uses SWT which actually uses native widgets.

    It's the slowest freaking thing I've ever used and it's even more hungry for memory than Firefox loading an AJAX web application. Once it finally gets loaded and running, it's fast enough for typing text.

    But every couple of minutes - FREEZE! It just stops. Best guess is that this is the Java garbage collector freezing the entire application for 10 seconds.

    Whenever it needs to load something (for example, to autocomplete some text) - FREEZE! The entire application stops for 10-20 seconds.

    Try and do anything more complicated than text editing, and you're in for even more slowdowns.

    So, no, Java being slow on the desktop is NOT A MYTH. If you've ever used a Java desktop application recently, you'd know that.

    Guess what, I use eclipse too. And I had the same freezing issue. The problem? Swap issues would cause eclipse to do a LOT of paging. Someone wrote a workaround for it, but upgrading to more than 512MB did the trick too. Once that happened, I never had a slowdown with eclipse.

    Actually, if you're having a 20 second slowdown for autocomplete, you're either running on a P3, or you're using waaaay too many libraries for your own good.

  • sf (unregistered) in reply to Anon
    Anon:
    aaawww:
    Anon:
    Imagine the speed of a Java desktop application, shrunk down and running on a cellphone...

    well, me thinks that some while ago the myth of slowness of java desktop applications was debunked...

    otho, i like to play the midp dweller roguelike

    When's the last time you used a Java desktop application? I use one daily, it's based on Eclipse, so any of the "it's just Swing" arguments can be chucked out the window because Eclipse uses SWT which actually uses native widgets.

    It's the slowest freaking thing I've ever used and it's even more hungry for memory than Firefox loading an AJAX web application. Once it finally gets loaded and running, it's fast enough for typing text.

    But every couple of minutes - FREEZE! It just stops. Best guess is that this is the Java garbage collector freezing the entire application for 10 seconds.

    Whenever it needs to load something (for example, to autocomplete some text) - FREEZE! The entire application stops for 10-20 seconds.

    Try and do anything more complicated than text editing, and you're in for even more slowdowns.

    So, no, Java being slow on the desktop is NOT A MYTH. If you've ever used a Java desktop application recently, you'd know that.

    Aaah... were you expecting a full-featured IDE NOT to use more memory than an AJAX web app? Try upping your JVM heap settings since the defaults are usually too small for a large java app like Eclipse. I've been using Eclipse since 1.x and I've never had your problem.

Leave a comment on “Out of Balance”

Log In or post as a guest

Replying to comment #:

« Return to Article