Interview with Fred van Kempen
Linux Journal: Lots of people know you for your code but there must be another side to you. What do you do for fun?
Fred: Apart from catching up my reading and sleeping every now and then (I tend to forget doing both of these...) hacking, listening to music a lot, and attending to family matters pretty much fill up my days. Hmm, perhaps people will now understand why my computers are named “metallica”, “bonjovi” and such? (smile)
Linux Journal: When did you get interested in computers? What inspired it?
Fred: In 1984 or so. Our school has this huge IBM (The Computer), which had all of our grades and such stuffed away. I then decided I'd be a computer technician one day...
Linux Journal: When did you first start working with Linux?
Fred: Uhm, in October 1991. I just switched from a 20MHz 286 to a 25MHz 386DX, and a giant hard disk crash terminated the Minix system that was running on it. I then tried a number of UNIXes on that machine, and ultimately a friend dropped some disks with the MCC 0.96c release. It ran pretty well, and was quite fast, even on the slow 25MHz CPU.
I had seen systems like 386BSD crawl on it, so...
Then, after installing stuff like news and such (all ports from the Minix system, as I got to like that stuff for its being small and simple) I started reading news again, and found that someone was about to release TCP/IP for Linux. This was just what I was doing with Minix at the time, and I decided to stick with Linux at least until after I checked the TCP/IP stuff. That, by the way, was Linux 0.98.
Linux Journal: For those unfamiliar with your contribution to the Linux effort, describe what you have done.
Fred: Well, mostly system cleanups (the Linux kernel structure has come a long way since 0.95 or so..) and of course the networking code. After some ugly flamish messages on the network, the original Linux NET author decided to quit the project, and I took over. Since then, the Linux NET code has been vastly improved, and it made Linux a real operating system, capable of competing with other UNIX-like systems like 386BSD and such.
Linux Journal: Why did you decide to do it?
Fred: I have always been doing network-related things, even in the era in which I was programming PDP-11 computers in assembly. Taking over the NET effort was natural, as I was already rewriting major parts of it, with in mind a system, compatible with “existing standards” as much as possible.
Linux Journal: Did you do the work alone or did others get involved?
Fred: I started out on my own, but later on several people joined the team. Of course, having multiple minds work on code is usually good for the code, because each person has a different view. I think the current NET development team is one of the better network programming teams around.
Linux Journal: Who are the others? Does each person have a specific task or area of expertise?
Fred: The others are:
Laurence Culhane: SLIP driver author, pre-alpha tester (firstname.lastname@example.org )
Mattew Dillon: Tester, “skb” code debugger, general race-condition tracer, tidbits-tracer (email@example.com)
Johannes Stille: TCP-hacker. Johannes spent a great deal of time on improving the TCP module, and the results are very good. Also, a lot of tracing, testing, etc. (firstname.lastname@example.org)
Terry Dawson: Testing, especially on slow (HAM) links which can cause very funny (ahem) situations. (email@example.com)
Fred Baumgarten: Testing, race-conditions, Netstat system, HAM link testing. (firstname.lastname@example.org)
Danny ter Haar: Testing the code, often with fatal results for his disks. We had some fun during the first set of “code cleanups” ... ;-)
Linux Journal: You are a ham, right? Does your Linux work and being a ham fit together?
Fred: Yes, I recently passed my US HAM test. Well, being someone highly interested in using and improving the art of digital communications over radio links, doing this on a system for which networking is natural is only a plus. The latest-and-greatest release of Linux Networking was designed to fit all kinds of networking experiments in an easy-to-implement way. As such, using Linux for HAM-like activities (meaning sending and receiving mail, talking to other people in general, exchanging knowledge and such) feels good. It's what made Linux in the first place...
Linux Journal: Does Linux work with AX.25 (amateur packet) code?
Fred: Yes. Right now, there are three ways to connect HAM equipment to a Linux machine:
Use the Linux version of the NOS software, either the WAMPES release, or the JNOS/Linux release. Personally, I prefer the JNOS code. This means running a user-level program, which handles all the ugly details. No kernel code is required.
Use the AX.25 kernel code currently developed by Alan Cox. This code works fine, but needs a modified kernel to run.
Use the new code I am writing for Linux. This is a long-term project, and right now, is only of interest for people who are willing to spend a lot of time re-implementing a set of horrible protocols. <laugh>
Linux Journal: Do you see a future for you and Linux?
Fred: Well, I certainly would hope so. I am co-owner of a US company which is trying to introduce Linux in the commercial market.
ARIS Technology, Inc (we usually call it ARIS, or even just ATI) is a small company located at the Technology Park of the Mississippi State University in Starkville, MS. It was founded by Dr. Michael L. Stokes, computer programmer and researcher at MSU's “Engineering for Research” (ERC) facility, and later I joined him.
ATI's short term plans are to consult with medium to large companies interested in bringing Internet into their business. We use Linux to do this when PC's will do the job because it will save money. As part of this plan, we will offer turn-key Linux systems through a local (Starkville) computer dealer. Longer term plans are to offer a commercial version of Linux based on Linux/PRO in CDROM, tape and diskette distributions.
This OS will offer a good stable platform for other commercial software vendors to support, and will support licensed software such as Motif 2.0, WordPerfect, etc. The distribution will be mostly licensed under GPL, though some custom desgined software will carry a license similar to SUN's (source code available free to licensed users for personal non-commercial use).
One of the advantages to this method of Linux availability could be that the commercial software developers, with all their great but usually DOS or “commercial UNIX”-based applications, may notice our efforts, and get interested in Linux as a platform to which they can port their products. Also, the fact that Linux is cheap has pushed many organizations and companies into installing it for business, fun or semi-personal use. After doing that, they usually find that a UNIX-like system, however cheap, needs a system administrator to keep it running smoothly. I think Linux created a lot of jobs in these fields, which is good...
Linux Journal: Do you have a vision of what the Linux community will look like in a few years?
Fred: Depending on what some of the recent Linux projects produce (I am talking about ELF/COFF, iBCS and Wine here), Linux users will either continue to be semi-hackers like now, who use Linux for fun (as there won't be any real applications) or standard things (mail, news etc.) or there may come some sort of shift towards the “business” and “semi-business” class of users, who use Linux systems for applications, like they would use a “any-commercial-UNIX-here” now. Right now, it is hard to say what will happen.
Personally, I think the Linux community will have to get used to (a) paying some money for the software they use (for example, shareware and commercial applications), and (b) a somewhat more closed development environment of the system itself. Many, many people will disagree, and exactly this program is what is keeping Linux from a major breakthrough in The Real World.
This really is a shame, because Linux has proved the fact that expensive, commercial software doesn't always do a job better than a free system. The only thing keeping the commercial systems ahead is the fact that they have the support of the third-party application developers, which Linux does not have.
Linux Journal: Thanks for taking the time to do this interview.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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