Slashdot Mirror

I recently read a Gartner Group report on free operating system software which was mentioned on Slashdot. It was interesting reading, and although I bristled at some of the assumptions and conclusions, it contained a number of valid points.

Many of us recognize the value of the free/open source model and would prefer to see it become a prominent model for software development and distribution. Our reasons vary widely, but among other things, it's simply more pleasant to work with open source products-- if I have to administer a system, I'd rather administer one that works well and that I can fix myself if something breaks.

So let's take some ownership here. We have the license to the source code, the rights to distribute the software, we've contributed code and documentation and tech support. Let's call open source operating systems "our products" and view the open source community as an entity that is in competition with the proprietary OS vendors.

If we want the open source model to prevail outside of its existing domain (mentioned in the report as "academia, application development, Web servers"-- that is, technical areas and the Internet), and assuming that the paper is valid, then we need to address the issues present in the paper. Here I am primarily addressing the Linux space, because it appears to be the free OS with the largest installed base, but the comments could be applied to our other OS products as well.

Most of the issues raised stem from this paragraph:

"Unix systems at free or minimal charge will lack the performance tuning, scalability and hardware platform support to make them suitable for large commercial applications through 2002 (0.9 probability)."

This statement surprised me in part. Linux appears to be a leader in scalability (from Itsy to Beowolf), has solid hardware support ( in many cases, least as strong as NT), and matches or outperforms other operating systems without tuning (e.g., SAMBA serving).

Looking closer at the report's arguments, though, is revealing. The authors suggest that Linux is weak in the areas of:

1. driver support (for newer or proprietary devices, this is undisputable true);
2. SMP beyond 4-way support (this is debatable);
3. NUMA support (none);
4. distributed systems and network management (e.g., OpenView, TME, Unicenter);
5. applications development;
6. performance tuning for high levels of scalability (">500 concurre OLTP users").

Items (a) and (e), driver and application development, are somewhat beyond the control of the development community, especially if these are taken to mean proprietary hardware driver support and proprietary commercial package application support.

However, to paraphrase a line from the movie Field of Dreams, "If you build it, they will come"-- if we take care of the other issues, the commercial vendors will add support. We have a couple of vendors porting their products to our OS's now, and this will snowball-- as commercial applications appear, more of our systems will appear in commercial settings, and more vendors will recognize the expanding market. All of the major DBMS vendors have said that they have at least an experimental Linux port in-house; it's just a matter of breaking the dam for the commercial-software-on-free-OS market to explode.

(Please realize: I'm not advocating proprietary vs. open source applications here, just recognizing that there is room in the world for both... but let's at least get them to work together on systems based on open source).

There are a number of things that we can do to address the other issues. Putting SMP and NUMA support aside for the moment (Linus is working hard on the SMP implementation and I think that it's moving well), we should concentrate on items (d) and (f).

Distributed Systems and Network Management: Our products are weak in this area. We don't plug into UniCenter (or TME or OpenView or anything else) and those systems can't be consoled on Linux. We can approach this problem in one of two ways: (i) we can write a network / distributed systems management tool; or (ii) we can write UniCenter plug-ins. I think that we should pursue both.

What if we offered to write the UniCenter plug-ins for CA in return for having them port the UniCenter console to Linux? Would they go for it? We won't know until we ask.

High Levels of Scalability: What a wretched phrase! Let's try "Scalabili ty to Very Large systems". If we can create Beowolf/Extreme Linux systems running into the gigaflops, surely we can come up with some amazing tpC figures.

Novell's UnixWare (back when it was Novell's and not SCO's) captured the attention of many IS managers when Oracle and Novell demonstrated record-breaking tpC and $/tpC figures. We should be able to do the same. There are some pieces we need to put together to make this fly:

• raw partition support for DBs would be good (these were used in the UW benchmarks);
• a commercial DBMS would be good (hey, Informix, here's your chance), or we can tweak PostgreSQL and friends into the stratosphere; and
• we'll need a hardware supplier, because the benchmarks should be on a standard system configuration (could be a mainstream vendor like Compaq or a Linux HW vendor like Paralogic).

  Conclusion: Our products in general and Linux in particular have got what it will take to beat the Gartner Group's predictions. However, we need to get our collective act together to push the envelope a bit in certain directions and then to prove to the world that open source OS's are competitive.

  David Cutler, director of Windows NT development at Microsoft (and architect of both VMS and NT) used to say somewhat rudely to his NT development team: "If you break the build, your ass is grass, and I'm the lawnmower."

  In a bigger sense, open source is a ride-'em mower being driven by a penguin, a gnu, and a little red guy wearing sneakers. Let's start the engine...

I recently read a Gartner Group report on free operating system software which was mentioned on Slashdot. It was interesting reading, and although I bristled at some of the assumptions and conclusions, it contained a number of valid points.

Many of us recognize the value of the free/open source model and would prefer to see it become a prominent model for software development and distribution. Our reasons vary widely, but among other things, it's simply more pleasant to work with open source products-- if I have to administer a system, I'd rather administer one that works well and that I can fix myself if something breaks.

So let's take some ownership here. We have the license to the source code, the rights to distribute the software, we've contributed code and documentation and tech support. Let's call open source operating systems "our products" and view the open source community as an entity that is in competition with the proprietary OS vendors.

If we want the open source model to prevail outside of its existing domain (mentioned in the report as "academia, application development, Web servers"-- that is, technical areas and the Internet), and assuming that the paper is valid, then we need to address the issues present in the paper. Here I am primarily addressing the Linux space, because it appears to be the free OS with the largest installed base, but the comments could be applied to our other OS products as well.

Most of the issues raised stem from this paragraph:

"Unix systems at free or minimal charge will lack the performance tuning, scalability and hardware platform support to make them suitable for large commercial applications through 2002 (0.9 probability)."

This statement surprised me in part. Linux appears to be a leader in scalability (from Itsy to Beowolf), has solid hardware support ( in many cases, least as strong as NT), and matches or outperforms other operating systems without tuning (e.g., SAMBA serving).

Looking closer at the report's arguments, though, is revealing. The authors suggest that Linux is weak in the areas of:

1. driver support (for newer or proprietary devices, this is undisputable true);
2. SMP beyond 4-way support (this is debatable);
3. NUMA support (none);
4. distributed systems and network management (e.g., OpenView, TME, Unicenter);
5. applications development;
6. performance tuning for high levels of scalability (">500 concurre OLTP users").

Items (a) and (e), driver and application development, are somewhat beyond the control of the development community, especially if these are taken to mean proprietary hardware driver support and proprietary commercial package application support.

However, to paraphrase a line from the movie Field of Dreams, "If you build it, they will come"-- if we take care of the other issues, the commercial vendors will add support. We have a couple of vendors porting their products to our OS's now, and this will snowball-- as commercial applications appear, more of our systems will appear in commercial settings, and more vendors will recognize the expanding market. All of the major DBMS vendors have said that they have at least an experimental Linux port in-house; it's just a matter of breaking the dam for the commercial-software-on-free-OS market to explode.

(Please realize: I'm not advocating proprietary vs. open source applications here, just recognizing that there is room in the world for both... but let's at least get them to work together on systems based on open source).

There are a number of things that we can do to address the other issues. Putting SMP and NUMA support aside for the moment (Linus is working hard on the SMP implementation and I think that it's moving well), we should concentrate on items (d) and (f).

Distributed Systems and Network Management: Our products are weak in this area. We don't plug into UniCenter (or TME or OpenView or anything else) and those systems can't be consoled on Linux. We can approach this problem in one of two ways: (i) we can write a network / distributed systems management tool; or (ii) we can write UniCenter plug-ins. I think that we should pursue both.

What if we offered to write the UniCenter plug-ins for CA in return for having them port the UniCenter console to Linux? Would they go for it? We won't know until we ask.

High Levels of Scalability: What a wretched phrase! Let's try "Scalabili ty to Very Large systems". If we can create Beowolf/Extreme Linux systems running into the gigaflops, surely we can come up with some amazing tpC figures.

Novell's UnixWare (back when it was Novell's and not SCO's) captured the attention of many IS managers when Oracle and Novell demonstrated record-breaking tpC and $/tpC figures. We should be able to do the same. There are some pieces we need to put together to make this fly:

• raw partition support for DBs would be good (these were used in the UW benchmarks);
• a commercial DBMS would be good (hey, Informix, here's your chance), or we can tweak PostgreSQL and friends into the stratosphere; and
• we'll need a hardware supplier, because the benchmarks should be on a standard system configuration (could be a mainstream vendor like Compaq or a Linux HW vendor like Paralogic).

  Conclusion: Our products in general and Linux in particular have got what it will take to beat the Gartner Group's predictions. However, we need to get our collective act together to push the envelope a bit in certain directions and then to prove to the world that open source OS's are competitive.

  David Cutler, director of Windows NT development at Microsoft (and architect of both VMS and NT) used to say somewhat rudely to his NT development team: "If you break the build, your ass is grass, and I'm the lawnmower."

  In a bigger sense, open source is a ride-'em mower being driven by a penguin, a gnu, and a little red guy wearing sneakers. Let's start the engine...

I recently read a Gartner Group report on free operating system software which was mentioned on Slashdot. It was interesting reading, and although I bristled at some of the assumptions and conclusions, it contained a number of valid points.

Many of us recognize the value of the free/open source model and would prefer to see it become a prominent model for software development and distribution. Our reasons vary widely, but among other things, it's simply more pleasant to work with open source products-- if I have to administer a system, I'd rather administer one that works well and that I can fix myself if something breaks.

So let's take some ownership here. We have the license to the source code, the rights to distribute the software, we've contributed code and documentation and tech support. Let's call open source operating systems "our products" and view the open source community as an entity that is in competition with the proprietary OS vendors.

If we want the open source model to prevail outside of its existing domain (mentioned in the report as "academia, application development, Web servers"-- that is, technical areas and the Internet), and assuming that the paper is valid, then we need to address the issues present in the paper. Here I am primarily addressing the Linux space, because it appears to be the free OS with the largest installed base, but the comments could be applied to our other OS products as well.

Most of the issues raised stem from this paragraph:

"Unix systems at free or minimal charge will lack the performance tuning, scalability and hardware platform support to make them suitable for large commercial applications through 2002 (0.9 probability)."

This statement surprised me in part. Linux appears to be a leader in scalability (from Itsy to Beowolf), has solid hardware support ( in many cases, least as strong as NT), and matches or outperforms other operating systems without tuning (e.g., SAMBA serving).

Looking closer at the report's arguments, though, is revealing. The authors suggest that Linux is weak in the areas of:

1. driver support (for newer or proprietary devices, this is undisputable true);
2. SMP beyond 4-way support (this is debatable);
3. NUMA support (none);
4. distributed systems and network management (e.g., OpenView, TME, Unicenter);
5. applications development;
6. performance tuning for high levels of scalability (">500 concurre OLTP users").

Items (a) and (e), driver and application development, are somewhat beyond the control of the development community, especially if these are taken to mean proprietary hardware driver support and proprietary commercial package application support.

However, to paraphrase a line from the movie Field of Dreams, "If you build it, they will come"-- if we take care of the other issues, the commercial vendors will add support. We have a couple of vendors porting their products to our OS's now, and this will snowball-- as commercial applications appear, more of our systems will appear in commercial settings, and more vendors will recognize the expanding market. All of the major DBMS vendors have said that they have at least an experimental Linux port in-house; it's just a matter of breaking the dam for the commercial-software-on-free-OS market to explode.

(Please realize: I'm not advocating proprietary vs. open source applications here, just recognizing that there is room in the world for both... but let's at least get them to work together on systems based on open source).

There are a number of things that we can do to address the other issues. Putting SMP and NUMA support aside for the moment (Linus is working hard on the SMP implementation and I think that it's moving well), we should concentrate on items (d) and (f).

Distributed Systems and Network Management: Our products are weak in this area. We don't plug into UniCenter (or TME or OpenView or anything else) and those systems can't be consoled on Linux. We can approach this problem in one of two ways: (i) we can write a network / distributed systems management tool; or (ii) we can write UniCenter plug-ins. I think that we should pursue both.

What if we offered to write the UniCenter plug-ins for CA in return for having them port the UniCenter console to Linux? Would they go for it? We won't know until we ask.

High Levels of Scalability: What a wretched phrase! Let's try "Scalabili ty to Very Large systems". If we can create Beowolf/Extreme Linux systems running into the gigaflops, surely we can come up with some amazing tpC figures.

Novell's UnixWare (back when it was Novell's and not SCO's) captured the attention of many IS managers when Oracle and Novell demonstrated record-breaking tpC and $/tpC figures. We should be able to do the same. There are some pieces we need to put together to make this fly:

• raw partition support for DBs would be good (these were used in the UW benchmarks);
• a commercial DBMS would be good (hey, Informix, here's your chance), or we can tweak PostgreSQL and friends into the stratosphere; and
• we'll need a hardware supplier, because the benchmarks should be on a standard system configuration (could be a mainstream vendor like Compaq or a Linux HW vendor like Paralogic).

  Conclusion: Our products in general and Linux in particular have got what it will take to beat the Gartner Group's predictions. However, we need to get our collective act together to push the envelope a bit in certain directions and then to prove to the world that open source OS's are competitive.

  David Cutler, director of Windows NT development at Microsoft (and architect of both VMS and NT) used to say somewhat rudely to his NT development team: "If you break the build, your ass is grass, and I'm the lawnmower."

  In a bigger sense, open source is a ride-'em mower being driven by a penguin, a gnu, and a little red guy wearing sneakers. Let's start the engine...