Spliced Networks acquires stealth startup

Spliced Networks will ring in the new year with the acquisition of a networking related stealth startup. The deal was signed and secured over the weekend. With this acquisition, Spliced Networks will extend its product portfolio to complete with Cisco, Vyatta and offer virtual layer 2-7 switching for use in blade and virtualized environments.

The benefits of this acquisition will be seen quickly, as Spliced Networks plans to ship the startup's Application Switch Accelerator during Q1 2008. An application switch is an advanced load balancing switch which has SSL acceleratior and DoS attack protection capabilities built in. The Application Switch Accelerator is designed to enhance existing Application Switch deployments by off-loading some of the CPU intensive tasks that limit the scalability of aging Application Switches. The accelerator allows customers to continue to enjoy the ROI on existing application switch deployments.

The acquisition will allow Spliced Networks to position AppOS to compete against VMware's Enterprise product line in 2008.

Fibre Channel over Ethernet

We have just added FCoE support to our storage line of SN-5000 series appliances. The Open FCoE project is relatively new, but their code held up well enough through our QA testing that we decided to provide this bleeding edge feature. The default SN-5400 and SN-5800 images just support iSCSI. FCoE, ATA over Ethernet and NFS will be supported as part of an optional feature-set.

FCoE basically encapsulates FC frames over ethernet. It works very similar to iSCSI in that it uses a target / initiator style system. FCoE enables the "cheap" deployment of FC over existing Ethernet rather than having to invest in more expensive and new infrastructure thats typically associated with Fibre Channel.

SN-5484 initial deployments

The SN-5400 series are multi-terabyte iSCSI storage appliances running AppOS 4.0. The SN-5484 is a 2U storage appliance with four 64-bit processor cores, 8GB of memory and 4TB of storage space. The SN-5484 has quad 1000BaseT connections, and one management port. The SN-5484 supports SAS (Serial Attached SCSI) as well as SATA-II. The SN-5484 can be built for under US$3000.

The SN-5484 is an enterprise grade storage solution shipping with Linux 2.6.23.9. The solution features a custom in-house developed storage stack by Spliced Networks. The first SN-5484 will go into production at Spliced Networks corporate head quarters in Athens, Ohio. The SN-5484 at Spliced Networks replaces the first generation storage appliances, the SN-5015.

The SN-5484 and SN-5888 storage appliances are currently being phased in at several customer sites as replacements for aging NetApp F760 and F820 series filers. The SN-5400 and SN-5800 series appliances will be listed on the Open Appliances site when it goes live later this month.

The storage solution stack will be available upon the GA release of AppOS 4.0.

Spliced Networks upgrades to Leopard

Here at Spliced Networks we use Fedora Core Linux workstations based on AMD Athlon64 X2 hardware, and multiple LCDs. However we use Apple Macbook and Macbook Pros for our mobile needs. We have a number of Mac Pro servers for development on the MacOS X platform as well. Today, we've moved the MacOS X systems to Leopard, without any problems.

Linux.com feels the heat

It seems that the traditional media is starting to feel the heat from o3 magazine's high quality, high tech content. Many of you were aware that we signed on Mayank Sharma as Editor in Chief. Mayank is a great young guy from India who works as a freelance open source journalist and editor. Mayank was being eased into the role of EiC, he has done a great job editing o3 articles and he just started writing for o3 with issue 9.

Following a week long visit from Linux.com Robin "Roblimo" Miller down in India, Mayank was forced by Linux.com to quit o3 magazine. We wish Mayank the best of luck with his future ventures. We already have two new editors signed up, but we are reworking some of the articles that Mayank had access to for issue 10.

We have decided to not run issue 11 on Ohio LinuxFest, as we felt the coverage over on our o3 linuxfest blog was sufficient. Instead, issue 11 will look at JeOS - "Just Enough OS". Both issues are on their way..

Spliced Networks adds 200MBit/sec in Europe

Spliced Networks has added multiple servers behind a 200MBit/sec connection at a new data center location in Germany. The new location will operate as the primary EU-NOC for Spliced Networks. The new location is expected to be rolled into production within the next week or so. Spliced Networks is expanding its resources in San Jose over the next week.

rPath down again for several hours

About a month ago rBuilder suffered from a rolling repository outage. The infrastructure problems continued this morning when large parts of rPath's infrastructure went down. This may or may not be related to the hour of maintenance conducted between 9pm and 10pm EST on rBuilder Online yesterday. But before 4.30am this morning (EST) large parts of rPath's web services were down according to Antonio Meireles, due to a bad proxy. Services were restored around 7.21am.

A quick look at rPath's infrastructure looks like it is just some colo sitting on some Cogent bandwidth. Nothing wrong with Cogent, we use Cogent in some places, but we're multi-homed and multi-site. A quick DNS lookup on www.rpath.com shows its on 38.100.0.24, the first IP in this block used for rPath appears to be 38.100.0.19 (colo-admin.rpath.com), with 38.100.0.28 appearing to be the last used (at least with configured reverse dns). Hardly enterprise grade, no redundancy, perhaps they should read o3 magazine! :)

Live logs from #conary:

[05:56:22] doniphon > large parts of rPath web down. bad proxy, etc.
[05:59:00] iwilson_ > I saw that
[05:59:11] iwilson_ > ironically enough, they die when I'm searching for something.
[05:59:16] tpfennig > oh downloads are slow today...
...
[06:06:14] doniphon > tpfennig: rBO is flacky atm. anyway fill a bug. *that* should not happen atm.
...
[07:09:35] doniphon > msw Up2 mkj jtate SM2k gxti *@rPath. wiki is down
[07:16:56] SM2k > doniphon: we're working on it
...
[07:21:19] msw > back///

Utility computing is going to cost you..

A quick browse of Web Hosting Talk's dedicated hosting offers forum, and you'll see that you can lease a nicely configured Intel Core Duo server, 1GB ram and 160GB of disk space on a dedicated unmetered 10MBit/sec link for around $130. Thats full duplex too, so about 3255 GB of transfer in each direction a month. Assuming we're not taxing the server too much, lets assume 20% CPU utilization. Plugging this same data into a utility computing service such as Amazon's S3/EC2, we end up with a bill over $590!! Prior to June 2007, it would have been almost $1000. So I could double up at the same data center ($260), and put two servers at another data center in Europe ($200), and still be UNDER the cost of an Amazon EC2 service by over $100. Not to mention that I've also got 4x the capacity. So this model really only makes sense if you can't administer your own server and like to throw away money!!

Ohio LinuxFest 2007 coverage

We've posted up the initial report from o3 of Ohio LinuxFest 2007. Check it out at here.

o3 magazine :: issue 9 is out

Issue 9 of o3 magazine is now available for download. This issue looks at Open Source Publishing using Open Office, Scribus and the GIMP. If you ever wanted to know how we put o3 magazine together, this is it.

o3 magazine on the iPhone

The Apple iPhone is one slick device, its effectively replaced four devices I typically cart around with me. Before the iPhone, I carried around my Motorola Razr, Dell Axim PDA, and pager. The iPhone effectively replaces each of these devices, as well as the iPod. Although I still keep the pager, don't trust AT&T SMS to be 100% reliable all the time!

Obviously one of the first things I did was try to read o3 magazine with the iPhone. It works flawlessly. Hats off to the Scribus team, because the PDF works very well, its easily readable holding the iPhone in either position. Even the o3 magazine site works fine on the iPhone. Very cool stuff.

So if you're away or simply want to read o3 while your traveling -- Get an iPhone!

Ohio LinuxFest 2007

Ohio LinuxFest 2007 is just a week away. If you plan on going or think you might go, you should register asap, seating is limited. This year, o3 magazine will be reporting live from the event. You can get our perspective of the event live from our o3 @ linuxfest blog.

o3 news goes LIVE!

o3 has expanded its offerings to include a daily Enterprise / Open Source news site. The new site is up on www.o3news.com. What o3 news is aiming to do is provide fast access to interesting Enterprise / Open source news. It is edited by professionals, for professionals. There is no mob mentality, so the technical, but less sensational articles don't get lost by the mob effect you see on Slashdot's Firehose or Digg.com. If its relevant and interesting, it gets posted. Right now we're getting news from a variety of sources, and as always its produced using just Open Source solutions.

Appliance partitioning without a hypervisor

The hypervisor is not an operating system replacement, its an operating system feature. Even VMware's ESX platform runs from within an operating system model. The Linux 2.6 kvm feature is a prime example of how a hypervisor can be easily and seamless integrated into the operating system. The kvm module gives the user the choice of running a hypervisor, to switch the feature on and off. This is in contrast to being told you have to run a hypervisor. I don't know about you, but I like having that choice, as not all applications need to run virtualized.

There are some folks that will completely disagree with me, try to tell you that the hypervisor is the death of the operating system. They should try Linux kvm, and then talk to the blade server people. Blade servers, remember when they first came out? The 1U rack mount server was dead, eh wait. Eh no, the 1U rack mount server is still here, yet all those vendors bounced up and down trying to convince you otherwise. Those marketing folks probably need to tone down the sugar content of their coffee! :)

A lot of customers looking at virtual appliances, really just want application partitioning. They want to be able to run DNS, SMTP, IMAPD and perhaps HTTP/HTTPS on a pair of really powerful servers, without worrying that SMTP might take the rest down. The reason for this might be that their needs are small enough, or they want high availability but don't want to invest in racks of servers. Perhaps they are using co-location and have limited space on their budget. It is this scenario where the marketing people are saying virtualization == security, when in reality thats not the case. What they really mean is that virtualization is providing application partitioning, and providing the advantage of securing those applications from each other. If you setup SMTP badly on a virtual appliance, its still going to be at risk.

So in reality, these customers don't actually want virtualization. What they want is a multi-role appliance with each appliance module partitioned from each other. This is what AppOS does, and has done since 2003. They want multi-role appliance partitioning but they think they want virtualization. You can get this with virtualization, but you can also get it with AppOS without the virtualization overhead. AppOS however, gives you the choice of running the solution in either mode. In the end, customers like flexibility and choice!

JeOS - its marketing not a new concept

The concept of JeOS is nothing new. The neat and effective buzz word JeOS (pronounced "juice") was coined by VMware product manager Srinivas Krishnamurti on his blog back on July 9th. The concept though is not new (sorry Billy), and we all know how badly things can go when marketing folks start promising features they've misunderstood.

Practically anyone who has created their own chroot environment, thats quite a few administrators over the years. Has already used the premise behind JeOS. Many enterprise grade devices such as layer 2-7 switches, content routers and hardware appliances have been using JeOS for years. JeOS is nothing new, and its not something that needs a hypervisor. JeOS is simple, its "Just Enough" operating system for what you are trying to do. OpenWRT is another example of a JeOS solution.

What JeOS is not is a packaging architecture. Package management does NOT belong on appliances, end of story. Don't believe me? Well lets think. What is mission critical and powers the Internet? Ah.. routers. Is there a yum update on Cisco IOS? Eh no. When you need to upgrade Cisco IOS, you download a new firmware image, and reload. Seems other vendors have taken this approach, and even the wireless lan products do this! Seeing a pattern? The self-contained image is guaranteed to work. Its tested for that specific hardware (or architecture) and it just works. When something is mission critical you can't afford to wait 5 minutes while it calculates dependencies, and then might have to roll back everything that it took 5 minutes to update in the first place because of an error. I'm not talking a flash / disk error either, what happens if you update a package and it corrupted at the source? Its got to roll everything back. This is why package management has no place on an enterprise grade appliance, its why trying to label JeOS as a packaging architecture is really silly.

So what is my take on next-generation server operating systems? Well the operating system should be an appliance delivery and management platform. It needs to provide the interface to the hardware (through drivers), access the management network (whether thats a separate physical network or just an SSL/IPSec VPN doesn't matter), exchange data with the centralized management system and then load the software appliances. Whether those are partitioned under a single kernel, or run as virtual software appliances is completely up to the user. In other words, virtualization should be a choice, not something force fed by some product marketing people.

The hypervisor is a feature, not a requirement. This is something very important to remember, because there really are applications out there where you need the full resources of the system available to you. There are bottlenecks which may not be acceptable, such as software switches and added latency of virtual interfaces. As well as the potential for packet leakage between virtual appliances. There are all potential problems.

Should JeOS be sold as a "one size fits all" of shared libraries and utilities? Quick answer to that is.. eh no. The JeOS solution needs to be minimal, very minimal. In fact it should be just enough to load the software (or virtual software) appliance. The libraries that the appliance uses such as libc, libxml2 and so on, should be part and parcel of the appliance itself. Could be part of a JeOS stack or as in AppOS -- Release Build Environment which provides basic libraries.

What happens if you are sharing libc and libxml2 between an Apache/PHP application and an Apache/Python application on the same server? Lets say the PHP application is compromised due to some unpatched PHP bug, this allows the malicious user to now manipulate libc, and thus effect the perfectly secure Apache/Python application! This is why sharing libraries between production applications is a very bad idea. It is why package management on an appliance is a very bad idea.

A better approach is to have each run its own dedicated copy of shared libraries. Sure this might waste a bit of disk space, but disk space is cheap, even more so with JeOS. This type of complete application partitioning is an important part of AppOS. The AppStacks for example, contain exactly what the application needs.

What I'm getting at here is that JeOS really comes in two pieces, there is the operating system side which provides the "just enough" part to load the appliance image, and manage it. Then you have the "just enough" libraries and utilities that are part and parcel of the software appliance itself. There is no kitchen sink situation for the libraries and utilities part. This is something the developer of the appliance needs to figure out, and provide as part of their solution.

The problem is there are companies out there who are trying to make a business out of dumbing down this development process. The development process should never be dumbed down, if someone who is providing a customer with an appliance cannot figure out that they need libxml2, libjpeg and openssl, and can't compile those from source. Do you really want to trust them with your business critical application? Remember any monkey can type [insert your favourite package manager] install openssl, but then you are relying on them to know that what that package provided is good and compiled properly. If they could do that, wouldn't they have just compiled it from source?

So JeOS is just that, Just Enough OS. Its a new marketing buzz word, not a new concept. If someone would like to dispute that, I'd like to point out that the very concept of JeOS (coined in July 2007) was part of my talk at Ohio LinuxFest 2006 (almost a year prior) on Open Source Zero Day Attack Protection. I just used the term minimal instead of just enough. Maybe I should have called it "Mince" ?

Tags: JeOS, virtual appliances, software appliances, ceos that code

Inside AppOS 4.0

AppOS is an open source appliance platform. You might be wondering where AppOS 1.0, 2.0 and 3.0 are? Until now, AppOS shipped as an integrated hardware / software solution. Customers purchased a 1U or 2U SN-series appliance directly from Spliced Networks or through one of our resellers. AppOS came pre-installed either of disk or on flash. Customers received automated updates and received a quarterly DVD in the mail with the source code.

Spliced Networks, unlike the majority of the other "appliance platform" companies out there, has actually shipped appliances and a lot of them. We have been there, understand the requirements, the process and the problems. This is why AppOS 4.0 is a far superior platform to the competition.

AppOS 4.0 sports all of the features we had in previous releases. The firmware style imaging system, the zero-day attack protection, the virtually instant OS upgrades and the centralized management system. With AppOS 4.0, we've improved on all of these features, further enhanced security and performance. However, with 4.0, we've introduced seamless virtualization without significantly increasing the image size.

AppOS 4.0 can switch seamlessly between our traditional AppOS image system, and a VM based system. It can run both systems simultaneously as well. Unlike other virtual appliances, AppOS 4.0 maintains its highly secure platform within the VM. Making it the most secure Linux-based appliance solution available today.

So if you are looking for the most secure, most highly optimized "JeOS", with the worlds smallest hypervisor built right in, stay tuned. AppOS 4.0 is coming.

Rethinking SaaS.. rBuilder impacted for 5 hours

Software as a Service (SaaS) is basically taking something you might run locally on a dedicated appliance, server or application and transforming it into a web based service. SaaS is great for some applications, such as this blog. However its bad for things which are risk adverse to downtime and data loss. Although I'd be a bit upset if my blog data was lost! :)

The big thing with SaaS is trust, do you trust the vendor thats providing the service, have they the skills and experience to run a highly available service? In other words, are they "Enterprise Ready" or not.

A business selling server appliances, whether its a hardware / software combination, software appliance or virtual appliance, should really take a close look at where they are doing their development.

Update:

Tim Gerla from rPath was kind enough to provide clarification on the outage below. Certain repositories were inaccessible over the course of 5 hours. This was a limited number of repositories. Repositories were read-only for a time. Tim apologized for the confusion regarding their announcement, and I'm sure they will provide more details with future announcements.

Since we always want to be fair and accurate, this update was added, the original posting is below and the title of this entry has been updated to be more accurate.

Thanks Tim!

End Update

For example, if you relied on rPath's rBuilder On-line service, you would have been straight out of luck for 5 hours this afternoon. Around 13:20 EST, rPath announced:

msw: rBO going into maint mode while we work on a db problem

Shortly after Michael Tharp updated the topic to indicate rBuilder Online is currently down for maintenance.

Over 5 hours later around 18:33 EST, rBuilder Online came back up, and Michael Tharp provided a quick update to indicate that it was back online.

A database problem shouldn't cause a 5 hour outage in a properly designed and highly available environment. Makes you wonder if its really ready for the Enterprise or just a nice packaging system alternative for the desktop?

JeOS .. Nice try but just too much

With VMworld wrapping up tomorrow, we are seeing the emergence of JeOS. JeOS is Just Enough OS, in the Ubuntu world its apparently 280MB. Nice try! Its not just the Canonical folks that are pumping this concept either. rPath seem to have jumped on the bandwagon too.

The concept of JeOS is not new, the fancy marketing buzzword is interesting but its unfortunate they didn't apply as much effort into engineering these solutions. Gentoo is smaller than 280MB, even Debian base is smaller than that so I'm not sure what kind of "juice" they've been passing around the Canonical offices, but 280MB is a joke.

Good to see that the industry is catching up with Spliced Networks. Took them over 4 years! AppOS 1.0 shipped as 160MB "JeOS", with 4.0 down to under 30MB, we must have the leading JeOS around!

Is GNU/Linux a trademark violation?

Linux is a registered trademark of Linus Torvalds and is administered by the Linux Mark Institute (www.linuxmark.org). The LMI will grant sub-licenses of the Linux trademark to businesses and groups that want to use the word Linux in their product.

When you refer to registered trademarks you are supposed to use the ® symbol, or at the very least attribute the mark to its owner. The folks over at GNU don't do this, if you check out www.gnu.org, there is no mention that Linux is a registered trademark, and they do not make any attempt to attribute the mark to Linus. The same thing goes for Debian, who I might point out have taken the measures to protect their own mark.

The use of GNU/Linux is an attempt to build a new mark from an existing one. Whether or not thats the intention, its essentially what is being done. In the case of Debian GNU/Linux, they are shipping a product (whether its free or not) so it likely falls outside of fair use.

GNU has great stuff, and they deserve every bit of praise and credit as Linux does. I would encourage businesses and entities who use GNU and Linux to build products, to mention that they are GNU-based as well as Linux-based. It is something we are doing with AppOS 4.0. While GNU has great stuff and deserves credit, they do not have the right to violate a registered trademark.

So is GNU/Linux a trademark violation? Should Stallman at the very least be required to get a sub-license? From my dealings with the USPTO (Patent and Trademark Office), GNU/Linux would seem to be a new mark, and thus require sub-licensing. If Linus does not enforce this, does it threaten the Linux mark ? Just some food for thought I would throw out there to the community.

Something for businesses to think about before adopting GNU/Linux instead of just Linux.

o3 magazine :: issue 8 - Enterprise Email

Issue 8 of o3 magazine is now available for download. This issue provides an end-to-end guide for building and deploying an enterprise-grade email system. o3 is a FREE digital magazine produced by Spliced Networks.

The basic idea behind the solution is to place multiple SMTP relays out there that use recipient lists and relay domains, along with the usual RBLs to cut through the bulk of the spam. The relays then forward mail to the per-domain configured server. This is usually a bunch of servers in a load balanced cluster, but could easily be a single server to. Its not listed on the public MX list, and in fact its firewalled so that only the SMTP relays and permitted client networks can talk to it.

The DSPAM article looks at dropping DSPAM in between the relays and the hidden back end SMTP server. The MTA we use is Postfix, but the recipes work under Linux, BSD and MacOS X. The DSPAM article provides a complete deployment guide. There is an article on Dovecot to provide imapd and pop3, with an article on Encrypting Mail protocols and finally a look at RoundCube to provide web based access.

We didn't stop there though, the issue also looks at Voicemail / Email integration with Asterisk, and we pushed the envelope a little with a look at voicemail to text translation with Julius, a real-time speech recognition project.

There is also an article on MobilityEmail, a good alternative to Outlook if you need to support Windows clients.

Finally, if you check the back page of the magazine, there is a little hint at whats on its way! :)

What would Cisco do?

The biggest problem with Linux server operating systems, whether its Red Hat Enterprise Linux, Novell's SuSE, or appliance new comers such as rPath Linux, is that they are all cut from the same cloth. There is no real innovation here. Sure, Red Hat occasionally will throw us a bone with things like GFS, or some cool innovative features in the kernel. There are very few operating systems willing to dance outside the safety of the status quo.

The problem is with the school of thought. The school of thought across all the developers and great folks that work at these companies is the same. There is nothing new there. If you look at rPath, you have Erik Troan, he was one of the original authors of RPM, the Red Hat Package Manager. Billy Marshall, CEO of rPath, he is ex-Red Hat too. Red Hat Enterprise Linux and SuSE, both RPM based, as is Mandriva. Even Ubuntu and Debian, while not RPM based, still have developers that essentially came from the same community with the same concepts that we've all seen Open Source grow up with.

What about Virtualization I hear you say? Virtualization is new. Yes it is, but what do our friends do? They bring package management and the very same line of thinking into Virtualization. It all comes down to one thing, its safe. The big companies like Red Hat and Novell, simply can't change over night. They are heavily invested in RPM, they have third party software vendors, certifications, and in essence, changing from package management, would be an admission that they were wrong. Why do startups follow this Lemming-like path? Well it makes it easier for customers to jump ship.

On the other side of the fence, you have companies like Cisco. Wait, what has Cisco got to do with Linux distributions? Whether you like it or not, Cisco is trusted with a major chunk of the Internet and corporate networks. Corporations are funny, they won't typically turn their business over to just anyone.

The Cisco 7200 series router is the workhorse for many businesses. Just like their other router and switching products, the 7200 runs IOS, their Internetworking Operating System. They use package management right -- NOT! IOS is shipped as a firmware image, a self contained system. When you upgrade from one version of IOS to another, you are completely replacing the system and rebooting. That IOS is specifically tested not only to work as a system, but to work on the very hardware that it runs on.

Look at all the businesses that provide critical wired or wireless infrastructure - Cisco, Nortel, Aruba Networks, Foundry, F5, Redback, Motorola etc. Look at your wireless router at home, it too provides a firmware image - self contained and tested.

This is the proven, time tested method for Enterprise networking, so why doesn't someone apply this to servers? Plain and simple -- school of thought. The folks behind the Linux distributions don't come from these backgrounds, and the few that may do, simply stick with the status quo.

That is of course with one exception -- AppOS, developed by Spliced Networks. For the past 5 years, Spliced Networks has applied the very same principles that make Cisco routers -- mission critical / enterprise ready to the Linux server. With AppOS 4.0, we'll make that very same solution available, de-coupled from the hardware!

Goodbye Package Management

Package management on an appliance is wrong -- plain and simple. The whole concept of an appliance is to have a contained system that has been fully tested and quality assured. When you introduce package management into such a system, you immediately lose the integrity and quality of the system.

Why ? A network-enabled package management system increases the number of variables involved for testing exponentially. A customer running a version of package X and a version of package Y , might decide to upgrade the version of package X, but has some custom application that upgrading package Y will break. This has produced a new type of system, one that has version 1 of package Y, and version 2 of package X. This might seem fairly simple, just create a QA test case for this scenario. Most Linux systems have hundreds of packages, as you start to scale up, you see that its no easy task to actually test each one of these scenarios. The moment you run update with yum, apt-get or conary, you've immediately stepped away from the QA blessed version of the operating system.

The problems however, don't stop there. Package management is making live changes to libraries, and executables on your system. The package management software is essentially, removing and install, or installing over the system. With automated systems such as conary, and systems you could automate like yum / apt-get, you run into a situation where human error is a factor, as is the integrity of the repositories you have to trust. What happens if in a rush to get a security fix out, a package isn't fully tested with the entire system, you grab your automated update, and next minute, your PHP applications stop working. Your only option is to roll back, and rolling back with package management (ask anyone who has used rpm for a few years) is a very hairy situation to be in.

What happens if your system is running a third party application, or your own custom application. It might have files open, that the package management system is trying to upgrade, and hence the package update fails unless those applications release the lock on the files in question, such as libraries.

Then of course there is the problem with your configuration. What happens if the system decides to update maybe bind, and this new release of bind may have changed a particular option you are using. Unless the package management system is designed to cater for this scenario, and in testing, we've found none that will do this effectively, your system is rendered unusable without manual intervention.

Package management is perfectly fine for the desktop, if something gets upgraded and it turns out to break your system, while its annoying, its not catastrophic. The same can't be said for the server or the appliance.

While some vendors would like you to think that a package management system is the way to go, its not. The only real advantage to package management on an appliance, is not to make the administration easy, but to make the development easier. In fact, package management adds a new point of failure and adds complexity to administration.

The real benefit is for the developer, yes thats right, the folks who are supposed to know their stuff, that you are entrusting the integrity of your business to, package management dumbs down their tasks for them. You might say, but this whole packaging system has complex configuration, how could it be dumbing things down?

Things are being dumbed down because the developer just needs to use a nice web interface, pick the packages that they need, perhaps add a few packages of their own and suddenly they are pitching to you this "Enterprise Ready" appliance solution. The fact of the matter is, they don't know when they imported openssl, who built it, if it contains patented algorithms, is it exportable and what extra patches it might contain. In some cases they could find that information out, but honestly, when they can click and roll, do you really think they have?

So whats going on here is essentially the "dumbing down" of the developer, the very person(s) who you trust your business to. Package management is bad all around for appliances, and it is far from Enterprise ready. The next time someone tries to tell you Ubuntu Server is Enterprise ready, ask them if Ubuntu has QA'd all the package management combinations, and you'll get a resounding... NO..

High Quality Articles Prevail

Despite the fact that we didn't make it to the front page of Digg.com or Slashdot.org, we were still able to bring home the bacon. As of this morning, o3 magazine had 208,898 readers of Issue 6. This is not bad at all considering we were off on hiatus for a year, and the issue is highly specialized!

For those interested in the geographical stats, here you go:

North America = 36%
Europe, Middle East, Africa = 54%
Asia Pacific = 10%

We expect to see at least another 100,000 readers pickup Issue 6 over the next 90 days. With past issues, not everyone is interested in a particular issue, but a future issue will get them hooked. They'll like the high quality articles, and head back for more by checking out past issues!!

Issue 7 is right around the corner.. stay tuned!

o3 magazine is back

On Monday we released Issue 6 of o3 magazine, the FREE digital Open Source / Business magazine that Spliced Networks started back in November 2005. So far, I am very pleased with the results since it has been almost a year since the last issue. The magazine is regaining momentum, and after only a few days.

Mayank Sharma is doing a great job with the magazine, Issue 7 will be out in a few days, covering Agile Product Management, again this is Open Source solutions that we are using in-house, so we're still drinking our own Koolaid!!

The GSLB solution is doing very well, considering it was pieced together over a couple of weekends. Nginx is an awesome piece of Open Source software, and I'm glad I found it. Hopefully I will get some time to submit a few patches to help polish its load balancing capabilities!