smashedbug.com, tech music and geek news

eWeek, the “Enterprise News & Reviews” site that provides news for a wide variety of decision makers in the IT field has an article on their site that discusses Linux to Windows migrations.

Needless to say, I was rather displeased with the article (right up there with the local newspaper article about computer viruses.. grr..) so I have decided to post my analysis of the article here.

Some large enterprises have taken the Linux challenge only to switch back to Windows, dissatisfied with the open-source alternative.

Ok. So large enterprises are switching back to Windows. Lets see .. they have case studies on Combe Inc. and Mountain High Holdings LLC, the operator of Mountain High Resort, a ski and snowboarding resort in Wrightwood, Calif. Combe Inc. produces various products such as “Just for Men”, “Maxim Haircolor”, “Sea-Bond”, and “Oder-Eaters”. While notable, perhaps a small/medium enterprise? Large? doubtful.

Mountain High Holdings, LLC apparently has the one resort .. again, not something I’d consider “large enterprise” — heck, I’m guessing not even an enterprise .. maybe a medium size business? Most likely a small business depending on definition.

“Even though [Linux] has moved into the realm of a production-level system and may become a competitor to Microsoft, that is just not the case where global support and robust development are required.”

Global support? IBM, Novell, Oracle, SuSE, RedHat don’t count? How about the LPI certified ISPs, Sun, Dell, Hewlett Packard and others? Robust development? Right.. I guess the fact that Linux and FOSS is the most de-centralized, globally distributed development currently occurring or the fact that the development tools are able to scale from embedded devices to thousand+ processor cluster supercomputers is not robust enough. Yup.

Case also was concerned that his company did not have appropriate in-house Linux expertise. Those concerns were proved worthwhile two years ago when the ISP gave Combe two weeks’ notice that it was closing its doors.

This is perhaps the biggest thing that gets me. Combe outsourced its web site operations 9 years ago (~1995) to an ISP that built their solution on Linux. During this time, Combe continues to run its internal operations on Windows (I’m guessing) and doesn’t have inhouse knowledge to support their site? So umm.. why didn’t they go with another Linux based ISP? I know of one good one *chuckle*.

Luckily, Combe had already begun investigating alternative ISPs. Not long after, Combe turned to Microsoft Certified Partner Alpine Business Systems, of Somerville, N.J., to help migrate its Web sites to Windows Server 2003, Internet Information Services 6.0 and SQL Server 2000.

Fascinating. Instead of going with another provider that they could easily transfer their site to, they get hooked up with a Microsoft Certified Partner that only knows Microsoft technologies. Seems to me the better route would be to pull their servers from the old ISP, drop them into another Linux savvy data center, adjust their DNS record and be done with it.

The move to Windows was “seamless and efficient. The costs to move were minimal as compared with the alternative of developing a new set of sites,” Case said. “We have not had an outage in two years, where before we experienced downtime at least two to three times a year. We have also lowered our TCO [total cost of ownership].”

This really confuses me. Why would they have to “develop a new set of sites” if they kept their Linux solution? Furthermore, why were they experiencing outages two to three times a year? Please don’t tell me they were running their site on the same box for those 7 years? Needless to say, it doesn’t appear that their current site is breaking a sweat, its copyright date is from 2001-2002, about the time they transitioned .. apparently they don’t update anymore.

Lets check out the other “large enterprise” case study…

Three years ago, the resort implemented an e-commerce system that used Red Hat Inc. Linux, The Apache Software Foundation’s Apache Web servers and MySQL AB’s MySQL database; the system was programmed in PHP.

Ok .. so they build a pretty standard small business style e-commerce site. Definitely not the tools of the “large enterprise” crowd, especially 3 years ago, but lets just go with it for now.

“The decision to go with Linux was a cost-based one,” Michele Roy, the resort’s chief financial officer, told eWEEK. “We had not budgeted the e-commerce system setup in that year’s business plan.”

uhhhh.. what?!?! They built an e-commerce site but didn’t budget for it?? Was someone having a blow-out sale on e-commerce sites 3 years ago that I was unaware of?? Perhaps “large enterprises” work that way .. deploy an e-commerce system without a budget. Cool.

“We spent more during the first three months troubleshooting the Linux system than if we had purchased the Windows solution to begin with,” she said. “The Linux system could not handle the layers of information needed for internal control of the resort.”

Ok I see .. lets do some roll playing:

Boss: “We need to get an e-commerce site up.”
Part-Time IT Guy: “Whats our budget?”
Boss: “Nothing.”
Part-Time IT Guy: “Hmm.. ok. I know some PHP and MySQL so I can hack together something and run it on one of the obsolete desktops..”
Boss: “Great!”

.. few weeks later…

Boss: “Why does the e-commerce site suck?”
Part-Time IT Guy: “Because its running on obsolete hardware and it was the first site I ever programmed and you didn’t give me a budget to use the correct tools or buy the correct hardware for the job.”
Boss: “My fault? NEVER! Your Fired, lets get Windows, it runs my Outlook.”

Summary..

1. Lage Enterprise #1 — Had Linux solution going for 7 years, switched over once their provided closed its doors, ended up hiring another provider that was unable to manage pre-existing solution and was able to sell the “large enterprise” on a completely new system (though to be honest, after 7 years on the web, it probably was time for an overhaul..)

2. Large Enterprise #2 — Built an e-commerce site with no budget, used the wrong tools for the job and most likely had an incompetent person do the programming for the site (seems about right given the toolset utilized). While the site worked for smaller loads, it ultimately fails due to the poor programming, not the operating system, database or other fundamentals of the system. Notable feature: This enterprise continued to maintain an online forum running on Linux.

Conclusion:

As always, inadequate budgets, poor planning and wrong vendors will ultimately kill a project. It doesn’t matter if the solution is built on Linux or Windows. I am particularly annoyed that a trade paper such as eWeek would post such a poor article equating these two companies to “Large Enterprises” and furthermore only focus in on a small subset of their entire IT infrastructure. At most it appears that Linux was the “odd man out” at both companies and as a result, internal IT knowledge was insufficient. On the bright side, given the number of case studies and migrations from Windows to Linux that have occurred or are currently in progress and this is the best eWeek could come up with for the reverse, perhaps it is a sign that people that are planning for Linux migrations properly are reaping huge benefits and NOT migrating back to the Microsoft lock-in.

Bottom line .. shame on you, eWeek, for having some a piss-poor article. The title should be “Two insignificant companies have inept management and make technology buying mistakes”.

The more I read into the entire philosophy of what FOSS is and how it has evolved impresses me. It makes me think back to Xerox PARC in the 1970s. For those of you who do not know, Xerox Palo Alto Research Center (PARC) was a flagship research division of Xerox Corporation, founded in 1970. The facility was strategicly positioned 3,000 miles from Xerox headquarters to allow it isolation from corporate desires.

During those early years, this research center on its own founded the graphical user interface (GUI), computer mouse, WYSIWYG text editor, laser printer, desktop computer, SmallTalk programming language, integrated development environment, Interpress (precursor to PostScript) and Ethernet, currently the most popular networking topology available.

The facility was able to function as an incubator for great technology for the sake of creating the technology. They were not put on a time frame or subjected to corporate focus groups or tied to some marketing scheme. Infact, many of the technologies, Xerox Corporate simply either did not understand or mismanaged providing the researchers or other companies to take the technologies and flourish into Fortune 500 firms (Apple, 3Com, Adobe to name a few..).

The reason I bring this up is to compare it with the FOSS development model. The model is largely governed by the individuals interested in the technology, much like the researchers at PARC. The separation from corporate objectives allows FOSS, much like PARC, to develop technologies at the speed that makes sense instead of some corporate agenda. Technologies do not have a pressing deadline where “just good enough” is accepted. As a result, as with PARC, technologies are fully developed and mature.

Whats particularly interesting is the openness. As with the resarchers at PARC, the FOSS community is very open to communication with others. Looking at complex problems from various viewpoints, determining the best way to address an issue and eventually coming up with ideas. Ideas are then subject to the communities approval and ideas and prototypes that don’t pass this litmus test are rejected. In many ways, the “good enough” that is so often the case in a corporate setting does not apply. The technology is priority, not a timeframe or budget sheet — much like at PARC.

The reason I bring this up is this blog entry from a Sun Microsystems engineer. He touts how Sun will not migrate to Linux because it is not “corporate” for Suns needs. His post goes on to discuss shortcomings (from his perspective) of the Linux kernel development. He sees the development cycle rejecting features, arguing that Linux should maintain binary driver compatibility “just like Solaris”. Needless to say, there was a rebuttal written (and quite fast) that shows a lack of understanding of the model.

One area I found particularly interesting was the issue of hardware drivers. In Windows (and other systems), when you get a piece of hardware, you usually get a driver disk to pop in the computer to install. The drive installs and you use the device. It is almost too common.

However, in Linux, a simple to install driver is usually NOT available along with the hardware. The idea (atleast my thoughts on it) was the kernel (the layer of source code between the hardware and applications) is able to be configured and recompiled to be optimized for particular hardware. As a result, unnecessary drivers are not loaded, the system is smaller (less memory usage), more secure and sometimes faster. As a result, certain elements of the kernel might be optimized in such a way that a pre-compiled driver could not function on that kernel.

Another reason was simple — if a system is totally FOSS, it would make sense that the drivers also be open source as well so auditing could occur. Makes sense — drivers can impact the stability of the entire system, it is logical to keep it open so others can fix issues in the event the original author is unable (or the OEM no longer maintains the hardware/driver).

However, whats interesting is the kernel developer writing the rebuttel brings up a great point. By including drivers with the kernel, it makes it possible to drop backwards compatibility much faster. Not to get into too much technical detail, the bottom line is there are revisions to various aspects of the system. For example, as USB devices flourished, the USB section of the kernel was rewritten several times (3 according to the author) to accommodate. The same thing occurred in Windows (ie Win98 version, W2k version, WinXP version..). With the drivers in open source format and provided for inclusion with the kernel, it is possible to do a search for use of the old functions (USB in this case) and allow an authorized kernel maintainer to update the driver to the latest revision.

The impact is dramatic. Instantly you can have all drivers that could benefit for the new, optimized USB code utilizing it. Second, the old USB code can be dropped from the kernel allowing it to be smaller, faster and more secure. Third, modern drivers for older hardware are available long after an OEM drops support for the particular product.

Compare this to the Windows model. In Windows, Microsoft keeps the old revisions of the USB code. So you have the 3 different revisions all included in the kernel. It is unknown what the drivers use (as they are binary and source is not available) and as a result, all the extra old code is loaded (3x as much bloat) even if it is not used. If you consider the amount of backwards compatibility in the system and the amount of revisions (even service packs have updated this aspect of Windows) to these API (application programming interfaces) it ends up slowing down the system, increasing memory usage and ultimately making it more difficult to secure as a built-in feature.

My point? Like PARC, the FOSS community is not subjected to corporate desires. Even though perhaps something is different and even looked at as a design flaw (from the perspective of a user of corporate built software), the FOSS community is generally right from a technological point of view. The end result? The software is built correctly without compromise. Sure, it might take a while to get it to that point and might not fit a corporate timeframe and might even be tough during the transition, but once it is done, it is done correctly.

Today, Linux ships with support for more hardware out of the box than any other system. All of this out of the box hardware support is due to the open source nature of the drivers which are systematically updated to utilize the latest features of the system to provide an up-to-date, stable, secure, simplified environment. Its reassuring that there is software out there that is built where a community will argue even smaller issues (read my entry regarding ClamAV’s distribution model) and not be afraid to reject large, corporate donated “improvements” (read the rebuttal) if it is not the best solution. Its nice.

X Windows, the popular graphical interface for Unix and Unix-like systems, is, by design, a network protocol. It works in a client-server fashion, like many network services. However, coming from only knowing how Windows and Macintosh worked, I was always in the mindset of one computer, one OS, one graphical interface. In that mindset I knew I could “hijack” another desktop by way of something like VNC (basically take screenshots and transmit them over the network) but for general computing, this is cumbersome, slow and insecure.

I decided to check out the network underpinnings of X to see what it was all about. I found that I was only one switch away from accessing the network features of X.

To use X over a secure channel, I was able to use my SSH client to setup the SSH tunnel (ssh joe@domain.tld) but with the switch to have it automatically setup the necessary items for X to function (ssh -X joe@domain.tld).

After using SSH to login to a remote system, I could then simply launch applications on the remote system by typing in the name of the app. Simple enough.

Since X is a client/server setup, the application RUNS on the remote system but simply sends the primitives to draw the interface locally. As a result, I can access all the information from the remote system as if I was actually sitting at that computer. I was able to launch my mail client (Thunderbird) remotely and have full access to my email and the capability of attaching files locating on the remote system without first having to transfer them to my local system. Pretty nice.

Whats the difference between this and something like VNC or perhaps NX (that I talked about a while ago)? First off, VNC and NX (well atleast the version I reviewed) work on a per desktop basis. As a result, I see the full desktop of the remote system inside of its own window. While useful, it feels and works like a “kludge”. Using X, the application launches right along side locally running applicaitons. I can copy and paste between the two, minimize the remote app to my task bar and it functions as a locally running application. In addition, it can send less information over the network (read: faster response) because it does not have to send pixel data like VNC.

However, the biggest advantage is the fact that any X desktop can be remotely accessible via SSH. As most Unix and Unix like systems now come with SSH as a standard service, it is very easy to log into a remote system and utilize its applications without first needing to get someone local to the system to install additional software before access is available.

Needless to say, this has made my Knoppix CD even more valuable. I can pop this CD into an Internet connected computer and be within minutes from all of my applications and software on my primary desktop. Very nice.

Of course, another great use would be for situations where several people need access to a resource intensive application (ie photo editing) — the photo editing application could run on a beefy server, less powerful client systems could connect remotely and access the app via X. The users would be able to harness all of the power of the beefy application server. Since the application is running on one machine, only one CPU license is required and with less powerful client computers accessing the system, it saves in hardware cost as well. Great way to reduce cost and maximize computer infrastructure usage.

Random, off the top of my head figures:

Remote X Window Access Configuration:

Traditional Configuration:

Interesting.

Free Open Source Software continues to amaze me. While it has been pretty well entrenched in the server world for several years, the recent push to the desktop has brought about a huge array of issues that so many in the industry concluded were too steep to overcome to gain any respectable marketshare.

However, the FOSS community (well atleast a good portion of it) is determined to make a viable FOSS desktop. Many in the community staked out desktop-centric distributions of Linux and added many userland graphical configuration tools, control panels and so forth to insulate the John Q. Public end-users from the “cold steel” UNIX underpinnings.

Out of this has come the very respectable KDE desktop environment, a full advanced productivity suite (OpenOffice.org), an absolute huge array of applications for multimedia playback & creation, productivity, desktop publishing, internet/networking, games and much more. In addition, advancements were made to the UNIX backend to allow it to be optimized for desktop functions.

While the alternatives (Windows, Mac OS, etc..) have been available for quite some time, the FOSS community has been able to quickly “get up to speed” while maintaining the core fundamentals that brought many to the UNIX platform in the first place (stability, security, reliability).

Nowadays, FOSS is starting to lead in various areas of development. For example, web browser technology. Apple based their Safari web browser on the FOSS KHTML rendering engine (developed by the KDE team). Firefox, the latest browser by the Mozilla FOSS team has been generating a LOT of press, is considered superior to other browsers and is the first browser to consistently take marketshare from Microsoft’s Internet Explorer. Infact, the latest version has far exceeded expectations in new browser downloads.

However, what I have found particularly interesting is the work the KDE team has been doing to lower the barrier of entry to application development.

With the latest KDE 3.3, bindings to allow scripting languages such as Ruby and Python have been included. As a result, anyone running KDE 3.3 will have the ability to run KDE applications written in these scripting languages without the need to install additional libraries or software.

Why is this “insanely cool”? First off, KDE is based on QT, a complete application development framework. The framework has the goal of being intuitive, easy and fun. This framework has been noted as achieving this goal and has consistently been considered the most intuitive and easy to use development framework.

However, it is coupled tightly to C++ which is a rather complex programming language. So what does the KDE team do? First off, they beef up Qt with additional user-land tools (such as KIO slaves, DCOP and others (read previous entries for info on these technologies)) and then integrates bindings to two of the most intuitive programming languages, Python and Ruby, available.

Bottom line? With KDE, it is possible to sit down without knowing any programming and start developing applications fairly quickly without having to learn a lot of computer software engineering lingo. Not only that, but in addition to this, these languages are not simply beginning languages like BASIC or Pascal, but fully capable languages that are used by professionals on a daily basis.

So whats the big deal? IMHO, KDE has become the perfect environment for computer education. Not only does it include all the essential business/education applications but can be utilized to explore the realm of programming and computer logic with the added bonus of teaching students a skill that can be used outside of the classroom.

In addition to this, the entire development platform is free (as in beer), capable of being run on different hardware platforms, and the languages are true programming languages that can be used for a wide variety of programming tasks.

I believe this focus on development tools will yield in an entire new generation of developers that will find FOSS to be a great platform for development work. As a result, the additional contributions by these new developers will ensure the continued improvement of KDE, the continued expansions of applications into various niche categories and the empowerment of end-users to truly harness the power of their computer instead of being limited to the shrink-wrapped desires of a software companies marketing department.

As you may be aware, the current notation for addressing on the Internet consists of the 32bits of data, normally found in the format: xxx.xxx.xxx.xxx where xxx is a number between 1 and 255. For example, your address might be 68.24.108.42.

This type of addressing is called “IPv4″ for Internet Protocol version 4. This dates back to the September 1981, well before anyone even thought the Internet would grow to the huge international network consisting of hundreds of millions of systems.

Today IP address space is harder to come by. There are international power struggles to maintain control of the losely allocated address space. Virtually all companies and organizations use NAT as a method of preserving IP space and dynamic IP assigning is prefered over static IP addresses in an effort to conserve addresses.

As a result, there is a push to deploy IPv6 (Internet Protocol v6) as the replacement for IPv4. Instead of being only 32bit like IPv4, the IPv6 standard calls for 128bit addressing.

Steve Deering of Xerox PARC at an MIT Lecture: “Many people thought that 64 bits for IPng addresses would not be enough. Some people seemed to think 64 bits could only hold numbers twice as large as today’s 32 bits could, but mostly people were concerned there be enough address space for tomorrow’s Internet toasters, wristwatches and automobiles. So we eventually settled on 128 bits, at which point no one had strong objections. It was then calculated that 2^128 was 1400 for every square angstrom on the surface of the Earth.”

And for all the people who don’t know how big an angstrom is.. apparently it is 1 hundred-millionth of a centimeter. A sheet of paper is 1,000,000 angstroms thick.

So lets calculate..

“Earth Surface Area: Land area, about 148,300,000 sq km, or about 30% of total surface area; water area, about 361,800,000 sq km, or about 70% of total surface area.” — Coble, Charles R; Murray, Elaine G; Rice, Dole R. Earth Science. Englewood Cliffs, NJ: Prentice-Hall, 1987: 102.

Total surface area of earth: 510,100,000 sq km = 5.10100 × 10^34 sq angstroms x 1400 IP addresses = 7.1414e+37 IP addresses (according to the professor)

IPv6 Space = 2^128 = 3.402823669209e+38 IP Addresses (according to umm.. math)

It appears from my quick calculations that the professor was off. I get 6670 IP addresses per sq angstrom.

I guess the question ends up being … why? Based on this calculation, the surface of a sheet of letter sized paper would receive 4.023508082e+22 IP addresses.. This ends up being the address space for 9,367,959,764,790 current IPv4 networks .. or in other words, every person, object and device in the entire earth could receive a unique, network addressable IP address and we would still not even come close to filling up even a fraction of the IP space in IPv6.

Perhaps I should start thinking about registering a domain like “JoesStuff.net” and as I add all my IPv6 goodies (toasters, cars, clocks, radios, pets, appliances, who knows what else..) I can simply make them all subdomains