April 2009

You can help write the next Franklin Award winner

Skepticlawyer, sometimes called Helen Dale, is working on a new novel. It will apparently include some ‘alternate history’ elements. She’s asking for people to chip in on a list of potential policies and historical twists in order to shore up her own thinking. I reckon the Troppo Army would be well qualified for such a task.

Blegs
Cross Posted from Club Troppo
Literature

Comments (0)

Permalink

Take that, Greek (and B-School) Mythology!

In ancient greece, the Oracle at Delphi drew its authority and oracular insight from Apollo, the Sun God. In the org-chart of ancient greece this made the Sun more important than the Oracle.

Of course the greeks had it wrong. The Oracle had knowledge; that made it a local power. Apollo received lip service, Delphi received pilgrims and gifts.

Echoes of greece have just taken place in the IT world. Database company Oracle have bought hardware and software company Sun. It’s the most important such event in quite a while and will make a big dent in the IT business landscape for the next decade or so.

My lame punditocratic take on this event below the fold.

The Background

The background to this is that Sun has been hit hard by the financial crisis. A substantial amount of their money was made in selling to big Wall Street firms and banks; that revenue stream suddenly stopped last year. Their sales force has been notorious for not wanting to sell a) their technological forays into cheaper servers or b) to any customer with less than 50,000 employees. Which hasn’t helped them at all.

A few months ago word came that Sun was in talks with IBM about a buyout. There was nothing Sun had that IBM could possibly need except for Sun’s customers. Sun held about 28% of the highend server market to IBM’s 38% share. Adding Sun’s customers to IBM would let IBM fight off Dell and HP with crushing numbers. As a bonus, IBM has heartily embraced Sun-owned programming language Java; having it come inhouse would be a nice bonus.

But otherwise, that deal was riddled with expensive redundancies. Every item in the Sun technology portfolio has a competitor – sometimes several – in the IBM portfolio. Sun has servers, IBM has servers. Sun has mainframes, IBM has mainframes. Sun has a Unix, IBM has a Unix. Sun has storage systems, IBM has storage systems. Sun has network gear, IBM has network gear. Sun has a database, IBM has a (much better) database. Sun has a Java stack, IBM has a Java stack. The overlaps go on and on. Once IBM had acquired Sun, it would spend the next decade migrating its new customers from Sun technology to IBM technology. Sun’s stuff would be left to wither, pure deadweight that came along with the customer base.

This would probably explain why IBM was playing hardball in negotiations. With Sun’s vulnerable position and the amount of technologies that they would inevitably kill off, IBM placed a lot of pressure on the Sun board to accept a “low ball” deal of around $6.5 billion for the company. Then, a few weeks ago, they walked away from the deal, apparently as a negotiating tactic.

Then, a few days ago, Oracle and Sun announced that Oracle had offered to buy Sun for $7.4 billion.

Why Oracle? Why Sun?

Oracle and Sun have a long history. Oracle was the first company to commercialise a Relational Database Management System, also called Oracle. Interestingly the background theory and prototype work for relational databases was actually carried out by IBM researchers. But the relational model for databases was incompatible with the network-model and hierarchical-model databases that IBM already sold to customers. It took outsiders to see the commercial potential. Oracle has grown to be massively profitable since then.

Sun was also an upstart. They began with “cheap”, powerful workstations for engineers, scientists, architects and the like, by combining the Unix operating system with mass-manufactured components. As time went on they maintained a commitment to R&D, including the development of their own CPU architecture (SPARC), more of which below. Eventually Sun grew into a successful major player in the Unix server market, which had already hollowed out much of IBM’s mainframe business from beneath.

Throughout this time, it was essentially “the done thing” for Oracle databases to be run on Sun’s Unix (SunOS, later called Solaris) on Sun’s hardware. Solaris on SPARC became the primary development target for Oracle and the two companies frequently cooperated to ensure a smooth, performant fit between the database, the operating system and the hardware.

So in some ways, the merger is obvious; the business fortunes of Sun and Oracle have been closely intertwined for decades. On the other hand, it came as a shock to many quarters, because here is Oracle, a pure software company, buying a mixed hardware/software company.

Reasons to buy Sun: the software

Oracle has very little duplication with Sun and they already have an overlapping customer base. This implies that they bought Sun for its technology portfolio and IP.

Some have suggested that it was purely for Sun’s formidable patent portfolio. This could be the case, but it would be much cheaper to simply license it. Sun would probably jump at an offer of one or two billion dollars for a long-term license deal, which would have been cheaper for Oracle. So they wanted something more.

Others have suggested that it’s a move to kill MySQL, a popular opensource database which belongs to Sun. But Oracle already owns the best bits of MySQL (the InnoDB engine) and besides, there’s currently no overlap between the high-end Oracle segment and the low-end MySQL segment. High-end customers wouldn’t trust MySQL, which has a terrible reputation amongst serious database nerds, and MySQL users are hardly likely to be suddenly seized of the need to buy $10,000 Oracle licenses. My guess is that MySQL is a kind of bonus for Oracle.

Are they buying the operating system, Solaris? Quite possibly. In the last few years Oracle have aggressively tried to move into the Linux operating system market, cognisant that Linux has been hollowing out the market of classic Unix vendors like Sun and that Oracle needed to be where the customers were. Oracle have a Linux variant of their own that they support, and Oracle programmers are among the most active contributors to the Linux project generally.

On the other hand, Oracle is still superbly adapted to the Solaris operating system. As a bonus, Solaris ships with technologies that have no Linux equivalent: in particular the Zettabyte File System (ZFS) and the DTrace debugging and inspection tool. ZFS and DTrace are exceptionally complimentary to Oracle’s core product; so much so that Oracle has been for some time leading and contributing to a ZFS-like project (The B-tree File System). So there’s evidence that Oracle have desired an operating system to call their own, and Solaris is an even better fit than Linux.

What about Java? This is a programming language originally developed by Sun for use in consumer devices, then marketed as a way to add programming to webpages, which finally found a home in “enterprise” computing. Java has been adopted very widely, including large investments by IBM and Oracle.

Java is an open source language these days, minus some caveats about the trademark itself. Several companies own “full stacks”. Sun had theirs, IBM had another one and Oracle through acquisitions had a third one. This is an area of duplication, so Oracle will likely mix and match their portfolio with Sun’s and dump some of the overlapping technologies.

It may be that owning Java is a ploy to gain leverage on IBM, or to put the hurt on them in some way. I’m not precisely sure how. IBM already own a complete, independent set of Java code and libraries. The licensing terms on Java are such that Oracle couldn’t really kill off competitors even if it wanted to. There’s some marketing cachet in owning Java, but I suspect that the cachet of being Oracle was enough already.

Reasons to buy Sun: the Hardware

Sun design and manufacture a lot of really cool hardware. They sell thin clients, low end servers, high end servers, mainframe-class servers, automated tape libraries, SANs, network switches and so on and so forth. Essentially you can, in theory, completely fit out your company with Sun gear without having to go to another vendor.

Of particular interest to Oracle is Sun’s T1 and T2 servers. These are built around a SPARC processor line called Niagara.

Niagara was a pretty bold break when it was announced. Instead of focusing on maximising inline performance, Sun set out to build a chip that could juggle a very large number of tasks with a relatively small amount of electricity. It was an extremely forward looking design: database and web server loads continue to climb and so does the cost of electricity.

Oracle contributed input to the design of the Niagara family and to its overdue successor, the Rock. These chips are extremely well suited to database workloads. A typical Oracle installation does a lot of transaction processing — keeping and updating records. Much of the information for these systems arrives simultaneously but affects different records. Consider a credit card company: many credit cards are getting swiped at any one moment, but each swipe only touches one card and one company at a time.

The design of the Niagara is such that each chip can keep working on a lot of such tasks simultaneously at a fast-enough pace, rather than trying to do one task at a time very quickly. The side effect of this simplify-and-replicate approach is that electricity use is driven right down for the same amount of database work.

But surely, Oracle is a software company …

There’s been wide speculation that Oracle will sell the hardware parts of Sun and keep the software. This comes from the business-school idea that companies should “stick to their knitting”.

The problem with the idea of sticking to knitting is that it just hides the question: what knitting? What’s the knitting scope? What is in the knitting and what isn’t?

So the traditional stick-to-knitting approach is to say “Oracle is a software company, they don’t sell hardware; ergo they will sell the hardware to IBM, HP or Sun’s former hardware partner Fujitsu”.

But suppose that Oracle isn’t in the software business. What if their knitting is “what our customers want from us”. Radical, I know!

Because one of the consequential ideas of sticking to knitting is that companies should jettison or outsource anything that doesn’t relate to their core business. Most companies don’t view establishing, running and updating IT systems as their core business, so the natural move is to pay someone else to do it for you. And nothing seems more attractive than to buy everything you need from the same shop.

Right now, only IBM own everything you could possibly want. They can build the entire network, they have all the software you need, and sell everything from laptops to desktops to servers to mainframes. It is possible to go to IBM with a fat chequebook and say “you handle all of it”.

Once the Oracle/Sun deal is complete, Oracle will be able to do the same thing. They will have the database, the business apps (which they’ve been acquiring for years) and now the hardware too. Right now Oracle can lose database sales to IBM’s own DB/2 product when big customers decide they want a single IT supplier. But now they’ll be able to chase the single-vendor business segment, which is growing. In fact they’ll have slightly more than IBM does, through the ownership of Sun’s Open Office suite.

So in fact, Oracle has an excellent incentive to retain the hardware business in order to defend and expand their existing portfolio, by becoming a single-source vendor for all things IT. This places them on a level playing field with IBM, who don’t seem to be suffering at all from being a most un-MBA-like IT conglomerate.

Afterword

I could be wrong. This merger is acting as a kind of Rorschach test for pundits. Everyone sees in it their favourite strategy or technology, because between them Oracle and Sun pretty much cover the whole spectrum of big-company IT. Do you think thin clients are the future? Then you see Oracle pushing the SunRay platform and dumping the servers. Do you think multi-core is the one true way? Then this acquisition is about Niagara and that its future is assured. Fan of strategic shennanigans? Then the acquisition is about hurting IBM on Java and the hardware parts of Sun are toast. Linux fan? You predict Solaris will be GPL’d and its tastiest morsels absorbed by the Linux kernel. Not a Linux fan? This is a sign that opensource is a dead end in terms of business strategy.

Right now we simply don’t know what Oracle is going to do. We won’t know until the deal is settled. But it certainly gives us grist for the mill for the next few months.

Update: I was right about SPARC. Larry Ellison says they’ll be keeping it; possibly adding features to improve database performance.

Business
Cross Posted from Club Troppo
IT and Internet

Comments (0)

Permalink

A sad day

Good old Spam Karma 2 has been trundled off to the glue factory. Ever since its maintainer threw in the towel because of the vague vagaries of Wordpress, SK2 has been living on borrowed time.

A few days ago the ever observant James A, sometime commenter here at Troppo, remarked that comment subscriptions seemed to be broken. It took us a while to suss out why.

One thing the comment-subscription plugin does, when deciding to send a comment by email, is to check whether that comment is approved and not spam. For whatever reason, SK2 was now reporting all new comments as spam, which meant they were ignored by the emailer.

I’m not sure why this is happening. SK2 hasn’t changed so the culprit is probably internal changes to Wordpress since 2.6. The Wordpress team do delight in changing the semantics of internal plumbing that plugins and themes rely on, then go on to enchant all comers by closing bug reports on their site with remarks about how it didn’t affect them so obviously it doesn’t affect anyone else.

In any case, with the maintenance of Spam Karma 2 falling behind Wordpress, it’s time to send the old warhorse to the knackers.

Cross Posted from Club Troppo
Site News

Comments (0)

Permalink

Some downtime today

Our hosts, the University Computer Club, have advised that there will be some downtime today between 11am and 12.15pm WA Standard Time. I hope you can all nurse yourselves through your Troppo withdrawals for this brief interlude.

Cross Posted from Club Troppo
Site News

Comments (0)

Permalink

Question

If I understand correctly, the $900 stimulus payment won’t be paid to people who earned less than $6000 last year — ie, those who did not pay net tax.

On a scale of 1 to 10, where 1 is a gale and 10 is cyclone Tracy multiplied by hurricane Katrina, how much of a poostorm is this going to generate when millions of folks discover they’re not going to get any “free” money?

I might be a libertarian, but until I crunched the numbers I was planning to spend the daylights out of the $900 I thought was coming my way.

Of course I might have misunderstood the numbers.

Cross Posted from Club Troppo
Politics - national

Comments (0)

Permalink

Payment woes continued

My startup dot-com project continues to plod along in the gap between university labs, assignments, tests and other studious miscellanea.

Today I spent some time getting down to the nuts and holts of payment systems.

I’ve done some work on this before, of course. Westpac knocked me back for their ordinary merchant account. I began to look further into third-party payment services. I have concluded that Australia is a terrible country for entrepreneurs who aren’t doing something ordinary.

To recap, these are my requirements from a merchant or payments facility:

It must:

  1. Allow me to bank with an Australian bank
  2. Provide multi-currency support. I need to be able to charge an amount in a currency and hold it in that currency — ie, it can’t be billed in USD and received in AUD. It has to be billed in USD, held in USD, then payed out in USD.
  3. Have some method of recurring billing where I do not hold credit card details.

I was chatting about this with other University Computer Club members today. Turns one of them is working on his own startup project (link removed by request) and has been facing many of the same problems as I have. His research found that for multi-currency support, you have to bank with NAB. Other banks let you run foreign currency accounts but won’t accept foreign currency credit card payments, which is one of my requirements. Apparently NAB will allow you to accept foreign currency payments and hold them in the original currency.

Apparently it requires a lot of harassing of NAB staff to make progress.

Then there are the fees.

NAB presumably realise that they’re the only one in this market. It’s $1200 to set up the account (vs $330 for Westpac’s AUD merchant facilities), plus various annual, monthly and transaction fees. On top of that you’ll want to use a payment gateway for the additional services they provide (like recurring billing), incurring additional fees.

For whatever reason, NAB don’t include foreign currency accounts in their online banking scheme. Unless you want to visit the bank in person to get a statement, and then type in all transactions into your accounting system manually, you’ll need to get a Windows PC with a modem to dial in to a special 1901 number instead. This is such bad service it makes my head hurt.

My fellow UCCer has said he is now seriously considering incorporating in Delaware. Opening and managing a US bank account may be cheaper and easier than doing it here in Australia. I guess I might have to do the same.

Anybody got tips on incorporating overseas? I’ve only just learned how to do it in Australia, after all.

Update: Inquiries at startup discussion site Hacker News have yielded more suggestions, including opening a bank account in Canada (the theory is that it’s a Commonwealth country but also next door to the USA) and also some advice that HSBC may offer what I need in Australia.

Update 2: HSBC don’t offer merchant services!

Blegs
Business
Cross Posted from Club Troppo
Startup

Comments (0)

Permalink

On a risk I had not considered

As most of you know by now, I’ve been slowly working in my spare time on a dot-com project. I haven’t knuckled down to do a proper risk analysis yet — let’s face it, coding is much more fun — but I’ve certainly kicked various scenarios around in my head while working on it.

So, for instance, I have design plans to use hash message digests on my server cookies, SSL encryption for most of the core components, outsourcing credit card management, keeping dollar amounts low to reduce incentives for fraudulent card users and so on and so forth. There’s heaps of nasty things that could happen.

I’ve been divided on how to manage server risks: what happens if one of my servers fails? In the early phases I’ve generally decided that this is a risk I will take on. My US provider (Slicehost) is reliable and quite capable. A search for “slicehost sucks” doesn’t turn up too many hits compared to some other firms. Slicehost manages various risks for me: power supply, fire, hardware failure, network disconnection. That’s what I pay them for, and they’re much better at it than I am.

But a few days ago the FBI swept into a Dallas data centre and took everything. And I do mean everything — every server, regardless of whose it was or what it was doing. The FBI have been known to seize individual servers or a handful here and there as part of investigations. They’ve built a rotten reputation for sitting on seized hardware for years and needing constant prodding and harassing to return it. Generally, the thinking goes, if the FBI take your stuff, you might as well write it off. It’s as good as gone.

The general way to manage FBI risk has been to prevent your server from being used for illegal purposes. Keep your server secure, keep the patches up to date, occasionally audit it, use security tools etc etc. If bad guys don’t start using your server, the FBI won’t track it down and take it.

But this is a new class of FBI risk. Now, my risk is based on the security of every server in the same data centre, which is something I cannot control. A commercial data centre could easily contain thousands of servers. A VPS provider like Slicehost could be running tens of thousands of virtual servers in a single centre. It is essentially a certainty that someone in that group has been cracked and has unwittingly started to serve illegal content.

Now I have to worry about dispersing my system across multiple data centres much, much sooner than I had planned to. Thanks a lot, FBI. You’ve basically added hours of work and a lot of extra expense to the plate of anyone who hosts servers in the USA.

Business
Cross Posted from Club Troppo
Geeky Musings
IT and Internet
Law

Comments (0)

Permalink