Interview: Orest Zborowski
Phil: I would like to get a little background on you.
Orest: I grew up in Connecticut and then got a degree from Duke in North Carolina. I had a dual major in Electrical Engineering and Computer Science. Then I went to work at Kodak in Rochester, New York for eight years working on publishing and printing software. Now I work at Microsoft.
Phil: Did you work on Unix systems at Kodak?
Orest: Yes, we started working with old Sun systems, possibly Sun 1s and then Sun 2s, Sun 3s and Sun 4s. Thus most of my Unix experience was with the BSD flavor of Unix. We initially worked with SunView then migrated to working with X11R4 and Open Look.
Phil: When did you get involved with Linux? And why?
Orest: Version .12 in 1992, I think. It seems like so long ago. I had played with Minix at home but didn't see it as being more than something that would run the ls command. I saw no chance to run X on it. Linux, however, had real memory management and looked like a possible platform for X and I wanted to give a port of X to Linux a try.
Phil: Did you consider one of the BSDs as an alternative to Linux?
Orest: Yes, I did, but at the time BSD required a dedicated machine rather than a partition on an otherwise MS- DOS disk; it offered no math co-processor emulation and just seemed less open than Linux.
Phil: So your first step was to get Linux up and running, and the next step for you was to port X to Linux?
Orest: Right. I saw Linux as a great platform for running X at home and considered it a good challenge to get things to work. Also, the number of available apps for X made having a Linux port very enticing.
Phil: What were the development steps?
Orest: X used a lot of [Unix] System 5 stuff so I decided that the job was to make Linux fit X rather than X fit Linux. That is, I started writing the needed System 5 system calls for Linux. The end result is that the X server for System 5 and Linux are almost identical. A side benefit is Linux now includes System 5 as well as BSD functionality. This has made porting other applications to Linux fairly easy.
Phil: What were the problems along the way? And when did things get exciting?
Orest: X11R5 was stable but the C libraries for Linux were still evolving, not to mention the kernel itself. The daily task was more dealing with what worked and didn't work in the libraries, which were changing quickly, than doing the actual X development. This was my intent as part of the make-Linux-fit-X effort.
I remember that producing a running X server was a great stress test of both the libraries and the kernel, and we found a number of subtle bugs and compatibility problems in the process.
Because there was no graphical screen code at the time, I wrote a curses driver so I could test the X server code. Getting the server working meant that sockets had to work as did networking and virtual terminals. The big breakthrough was when the server came up with my curses driver. Because each pixel was represented as a dot in character mode, all I could see was an 80x24 patch of the “display” but there it was: the biggest “X” cursor in the world sitting over a huge xterm shell prompt. Huge, but it did work.
Once I was at this point, it was fairly easy to then add the other code to get the video to work in graphics mode. At this point, the pre-XFree86 team was gearing up (I call it “pre-XFree86” because it wasn't called that until much later). David Wexelblat and David Dawes, along with a small group, decided to actively support X11R5 on 386 platforms. This was a tremendous boon for Linux and I never dreamed that XFree86 would become what it is today.
Phil: The X development team has a different organizational structure than Linux. Well, actually, X has a structure, but Linux decisions really just use the “send it to Linus approach”. How do you feel about this?
Orest: XFree development is more controlled than Linux. They use the BSD method rather than the Linux method. This has put some people off, but it really isn't a problem. In fact, it may be better for X development. Linux development has been very open and we all appreciate that. But Linux development lends itself more to that sort of environment than X, where a tighter decision-making mechanism is needed. I don't think there are any cases where reasonable suggestions have been ignored. People are always welcome to join the team, but the level of involvement may scare off those who only wish to dabble. The current group of active developers spend a lot of time with XFree86.
Today, Linux development needs to maintain backward compability. For that reason I ran the 1.0.9 kernel on my development system until 1.2 came out so I could make sure that new code would not break on the last production kernel.
It is important that Linux offer a stable, reliable path for upgrading as many of today's users are actually just that: users. They use Linux as the operating system upon which they run an application rather than develop software for Linux or modify Linux itself.
Phil: Are you currently doing any X development?
Orest: Yes. I am working on moving the X distribution to use ELF libraries. The next release of XFree86, 3.1.2, will probably be a maintenance release where the main distribution will still use a.out binaries, but ELF binaries will be included as well.
I am also doing little things here and there, but it's not the same level of involvement that there used to be. The package has gotten to such a point where it is instantly useful to a very large group of people. New development within XFree86 centers on new drivers and support for future XC projects.
Phil: Let's predict the future. Where is Linux going, and then, where do you fit in to that future?
Orest: To be commercially viable, Linux needs applications. The CD manufacturers, to their credit, are trying to make a “shrink-wrapped” version of Linux. What they have done so far is good but there needs to be more.
Phil: And what is “more”?
Orest: First, you need easy answers to questions like “can you run blank under Linux”. My sister, for example, runs some computer applications that aren't available for Linux. She would also need a nice graphical interface to system management; something as close to “load and go” as possible.
Phil: Okay, what would your sister need available to make Linux a viable choice?
Orest: Word processing, a stat package and a database.
Phil: The big one missing here is a word processor. I don't think she wants vi and troff.
Orest: Nope. And there are quite a few people without the technical expertise to handle such low-level software. They want to be productive—to solve their problems. Linux can provide a much better platform than anything else to develop these solutions, but the solutions themselves are not quite there.
Phil: How about a package that had all these applications in them plus a phone book.
Orest: And a scheduling package, and then you would have something that would meet the needs of an average PC user. The basic question to answer is, “Why should I run Linux rather than another operating system?” The apps we design need to be something that's difficult, if not impossible, to produce on any other platform available today. And note, the competition is not standing still, either. Comparing today's plans against today's commercial offerings means being instantly obsolete once those plans are realized and the competition has had time to catch up.
Phil: What if we add an Internet-access package? That would use the real multi-tasking capabilities and included networking of Linux.
Orest: Yes, I think we are on the right track.
Phil: Okay, where do you fit into this future?
Orest: I am working on some packages like these. I am really interested in working on this but I have a job which takes up quite a bit of my time. I know this is a common problem.
Because of the delays of the Internet and the part-time nature of people working over the Internet, I think this would need to be done commercially rather than as a cooperative effort over the net. Full-time, highly-focused development has obvious advantages. That's where you can take the time to really put together something nice—nice enough for my sister to use.
Phil: If I won the lottery and had money to burn, what do you think it would take to make this whole package a reality?
Orest: A team of 10-20 people could make the package to end all packages we discussed above happen.
Phil: I'll let you know if I win the lottery. In the meantime, thanks for taking the time for this interview.
Orest: You're welcome. I enjoyed it.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python