Saturday, September 29, 2007
Ohio LinuxFest 2007 coverage
We've posted up the initial report from o3 of Ohio LinuxFest 2007. Check it out at here.
Tuesday, September 25, 2007
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.
Saturday, September 22, 2007
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!
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!
Friday, September 21, 2007
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.
Wednesday, September 19, 2007
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.
Sunday, September 16, 2007
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!
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!
Saturday, September 15, 2007
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
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
Subscribe to:
Posts (Atom)
