LJ Interviews Larry Augustin
VA Research was founded in 1993 to develop affordable workstation, server and Internet products using the Linux operating system. I did an interview with Larry Augustin, their founder and President, by e-mail on August 19, 1997.
Marjorie: Tell us how you first became interested in Linux.
Larry: It was during the time that I was a Ph.D. student at Stanford University in the summer of 1993. I did a fair amount of system administration work in our lab. I was also consulting and doing system administration at Fintronic USA, an ECAD software company. At the same time Linux was beginning to come into its own. By that I mean, the essentials such as X and NFS were supported. The Linux environment was pretty close to our primary development platform, Sun OS 4.1.3; so, we decided it was time to replace Sun with Linux. I set up a 66MHz 486 machine running Linux for around $2000 and ported my thesis (15,000 lines of C/C++ code and 300 pages of LaTeX) as the first test case. Even though my code was very Sun dependent, it took me less than a day to port it to Linux. Compared to the SPARCstation 2 machines we had ($7000 base price), the 486 running Linux ran my code 1.5 to 2 times faster. I was sold. By the way, we still use that first 486 at VA Research in Receiving.
Marjorie: Since you come from the West Coast which is traditional BSD and Sun OS territory, what factors made you decide to choose Linux over BSD?
Larry: Actually, my first exposure to Unix was System V Release 3 at AT&T Bell Labs. I spent two years there, beginning in 1984. So some of the System V leanings of Linux appealed to me. One thing I liked about Linux was the way it combined the best of System V and BSD. For example, I liked the combination of System V run levels with BSD-style rc scripts used in SLS and later Slackware. I also tried FreeBSD on that same machine that first ran Linux. FreeBSD was extremely appealing because I was so familiar with Sun OS. At the same time, FreeBSD was missing important features like shared libraries, and it didn't have the user base or the developer base of Linux. It was also slower than Linux. The trend was all Linux, and I didn't see BSD catching up.
Marjorie: What made you decide to go into the Linux business?
Larry: James Vera, another Ph.D. student at Stanford, looked at the Linux machines we had put together and compared them to the SPARCstation we were using. They were 1.5 to 2 times faster, cost one-third as much, had more software and also ran DOS/Windows. We showed them off and people said, “Can you put one together for me?” Graduate students can always use more money and another excuse not to work on their thesis, so we decided to put together systems for people on weekends. The original idea was to gather all the components in my apartment and have an assembly party. The concept was simple, but it turned out to be a lot more complicated. As one of the venture capital people we talked to later put it, “the proverbial lemonade stand”.
The 1993 equivalent of the lemonade stand was the web page, which we ran out of Fintronic, where I did consulting work. Those first web pages were really ugly, but they contained a lot of information that appealed to people. We'd done our homework: benchmarked different configurations, tested different video cards, etc. We thought we had a pretty nice machine for the money.
Marjorie: Sounds as if you almost went into the web business rather than the Linux business.
Larry: We didn't necessarily plan to build a business around Linux workstations when we started our “lemonade stand”. It was originally a part-time business. We'd been doing it about six months and business was getting to be more than we could handle. During that time, two other friends of mine from Stanford, David Filo and Jerry Yang, were having the same problem with a little web site they had developed called Yahoo. James and I were working full time on Linux, and Dave and Jerry were working full time putting URLs into Yahoo. Not a lot of work was getting done at Stanford.
Dave, Jerry, James, myself and another friend, David Ku, began writing business plans for Internet-based businesses. We wrote a couple of business plans together, but none of them really clicked. We were each being pulled into the separate directions we had already taken. Dave and Jerry ended up with Yahoo going public and making $150 million each. Now I tell people that my claim to fame was writing a business plan with Jerry Yang and David Filo and turning down $150 million to work on Linux.
Marjorie: When did you make your first sale?
Larry: It was in November 1993. It wasn't a complete disaster, but we did learn that being in the hardware business is not easy. Lots of things went wrong. First, we were using the Orchid Fahrenheit video cards based on the S3-028 chip set. The cards we received for that first order came with a different BIOS revision than the cards we had tested and didn't work with X, and the multi-I/O cards we had tested were out of stock. We eventually got things worked out, but it was not as easy as we had thought it would be.
The process we followed with all our components was fairly straightforward. We'd get samples of 3 or 4 of the best-looking products in a category based on our experience and comments on the Internet. Then, we would test and benchmark them and use the best ones. But it's not always that easy. First, manufacturers are always doing product revisions like the BIOS change. When you're doing only a few parts a month, it's really hard to get the same revision of anything. Manufacturers also change revisions and don't tell you. We had that problem again recently with Matrox. The Matrox Millennium used to work in 24-bit color mode with XFree86, then Matrox did a BIOS upgrade. So, we had to get the information on the new BIOS back to the XFree86 core team.
We also discovered there is a lot of bad cache and RAM out there. We now qualify each brand of SIMM or DIMM down to the specific chips used with each motherboard. We used to think you could buy any quality brand memory and expect it to work with any quality brand motherboard—that's not true. We now use only memory qualified with each board.
In general, for a given manufacturer, quality differs by manufacturing lot. For example, we'd have a disc drive that looked okay, and then receive a batch with 50% failure rates.
We ended up developing a whole set of checklists and test procedures for every system. Benchmarking each system is also important since some errors only show up as performance problems. Things have also gotten easier, as we have grown. We can now qualify batches of 50 and 100 components all from the same manufacturing lot. That helps somewhat, but one thing we have learned is that there's a lot more junk out there than we thought.
Marjorie: What do you think are the key barriers to acceptance of Linux in the corporate world?
Larry: First, I think that by “acceptance” we mean acceptance by corporate MIS departments. Most of the Fortune 500 already use Linux but corporate MIS doesn't know it. The feedback we get from the traditional magazines like UNIX REVIEW, which are primarily Fortune 500, is that Linux is well established among their subscribers. Usually, it's because a developer or system administrator snuck a machine past the corporate people. Eventually, the MIS people discover the machine because some application is costing less and running better. This strategy of sneaking it in the back door seems pretty common.
For example, a good story I heard recently was from Cisco. Cisco has 10,000 people and 1600 printers worldwide. Two years ago they had a horrible management problem with printers. They could never tell what was happening with a networked printer, since hundreds of people on dozens of systems could all spool jobs to that printer. The system administrator responsible for printers began designing a scheme where all print jobs for a given printer went through one spooling machine. The spooling machines needed to be able to talk to all kinds of clients (Windows, NT, Unix, Novell, etc.); they needed to be inexpensive enough that they could deploy hundreds of them; they needed to be reliable; and they needed to be remotely administered. Now all of those 10,000 people around the world can print to any one of those 1600 printers anywhere else in the world, and all those print jobs are spooled through Linux machines.
Marjorie: Continuing that same subject, what are the barriers to corporate MIS?
Larry: Support is a big one. Corporate MIS wants someone to take responsibility. We all know Linux has incredible support through the Internet, but that's not the same as having someone's name on a legal document guaranteeing support. That's where the commercial Linux vendors like Caldera, Red Hat and VA Research come in—the MIS people need to see a large stable company that will be there to back them up.
Applications is another big one. Ninety-five percent of the corporate world doesn't care what OS the desktop runs, but whatever OS it is, they want it to run the latest version of Microsoft Office. You can see the power of Microsoft Office in the recent deal Apple struck with Microsoft.
Perception is one of the barriers I don't think people give enough weight to. The corporate world has to perceive Linux as friendly to corporate MIS people. The perception that Linux is for hackers only has to change. People in the Linux world need to project a courteous and professional image.
Marjorie: How does VA Research support the Linux community?
Larry: First, we host the Silicon Valley Linux Users Group (SVLUG) and the Debian project on machines at VA. That means we provide them with machines and network access. We also sponsor SVLUG in other ways, such as providing space for install fests and workshops. Usually, you'll find a couple of VA people at the install fests helping out.
Also, we maintain a fairly complete FAQ and related support information on our tech support web pages. These are available to anyone, not just our customers.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide