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.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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