Since people are asking.

http://mexico.purplecow.org/tmp/illumos-msosug.pdf

Now that Illumos has launched, it’s time to get involved. Register for the website and participate in the forums and don’t forget to subscribe to the mailing lists.

cut&paste:

Unofficial audio streams

It is recommended you connect from a Windows or MacOS as gotomeeting is known to work well over these platforms.

If you cannot for some reason, Matt Lewandowsky is setting up an audio broadcast stream at
http://www.greenviolet.net/articles/illumos-announcement-stream.gv

Illumos will be announced publicly at a conference call on Aug 3, 1PM, EDT (That’s 3am, Australian Eastern Standard Time).

To join this call, head over to the below link, and register your mail ID for the call information.

https://www2.gotomeeting.com/register/785845675

You can join in two ways:
Call in via phone
Call via Voip (mic/speakers)

The access details will be sent in an email once you register.

Original Announcement: http://www.illumos.org/projects/site/wiki/Announcement

EU clears Oracle/Sun merger.

http://www.oracle.com/technology/software/products/database/oracle11g/112010_sparc_x64soft.html

Just a quick note / reminder that iView support came in with the 3.1 firmware update, so install that update and tune in. Australian PS3 cultists only.

http://www.abc.net.au/corp/pubs/media/s2662012.htm

Solaris 10 update 8 (10/09) has been released. New features documentation here.

Looks like Sidekick users are having bad weather in their Clowd, which serves as a reminder that hosted services aren’t the magical sure-fire solution to avoiding infrastructure management.

We tend to assume that online facilities, especially those provided by large organizations are going to be reliable, trustworthy and better administered than a small-budget local solution. We expect redundant servers, storage, backups, probably even multi-homed networks.

“They’re still looking for a way to recover it, but they’re not giving users a lot of hope”

Normally, a critical server failure has a recovery plan - “tape time”. When everything fails, rebuild the servers, restore from tape and get the show back on the road. This takes time but the data comes back.

For a major carrier to have an outage with no solid recovery plan, which implies no disaster recovery solution such as an off-site replication target is a surprise - but should it be? These sort of hosted services are pitched as being cheap or free, so should user expectations be so high?

If you’re not paying for a level of service, how can one expect that service to hit the reliability level that you know you’d achieve running it in-house?

When we deploy, for example, an in-house mail solution, we will have (generally) as a minimum

1. Multiple MXes, including a secondary on a remote network
2. Regular backups
3. A restoration plan to make use of those backups

But when we outsource our mail to a third-party provider, unless they actually make a sales position of their infrastructure and preparedness, how do we know if they’ll survive a server failure? A faulted storage array with data corruption?

I think the lesson to be learned from this failure isn’t just for Sidekick users - it’s for everyone using hosted services in a manner in which would lead to a problem if they went away.

How much impact would the loss of email, calendaring, contact management and instant messaging have on your day?

Most desktop workloads that don’t require high-end video or large amounts of I/O seem to be natural VDI candidates. General browsing, office applications and the like really do hum along nicely and really would lend themselves to a Clowd (heh) deployment.

Except one.

Except one really popular desktop application in business.

Outlook.

Outlook 2007 seems to be able to rip-snort through more I/O bandwidth than you’d believe. I have Outlook running in a VDI session for work purposes, and wow - as it crunches through multi-gigabyte .OST and .PST files, it really keeps the I/O roaring pretty heavily. I keep those files on a seperate server to the rest of the VDI storage, because it was competing too heavily for resources. A quick run of iostat -xn on *that* host tells me Outlook is sustaining 10Mbyte/sec of I/O for a long time, especially when “checking” after an unclean termination. I get the feeling it’d eat more if there was more network bandwidth for it to eat.

Now, this leaves me pondering a modest 200 seat VDI deployment. After some sort of server interruption, that could be 200 seats logging in at 9am and firing up Outlook - this could seriously impact network and storage performance and leave a lot of users taking long morning coffee breaks while their system grinds to life.

Comments, anyone? I’d like to think this is a solved problem, given the popularity of Outlook on the desktop.