Slashdot Mirror

fatcat writes "Original statement on XFree.org regarding the NVIDIA source code." H:I've also included the statement-click below to read it. After we had finalized XFree86 3.3.3, and within hours of our planned release, NVIDIA insisted that we withdraw two source files from the driver that they had supplied to us and replace some other source files with versions that were partly run through the C preprocessor. NVIDIA's stated reason for this was to remove some of the names that they thought might reveal intellectual property from NVIDIA. This resulted in somewhat unreadable and unmaintainable code. The XFree86 Project is strongly opposed to such obfuscated code. Among other things, such code does not satisfy the Open Source definition of "Source Code", which states that The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. Due to the extremely late date of this decision by NVIDIA, we decided to include the code as offered by NVIDIA. All other options would have significantly delayed the release of XFree86-3.3.3. We'll try to work with NVIDIA to find a more acceptable solution so that the code can remain in future releases.

nlucent writes " a brief history of computer hackers/hacking from RMS and the FSF, to kevin mitnick, and K & R. covers the birth of unix, the arpanet etc. " Ladies and gentleman, this is from the discovery channel. Hacking is documentary material now.

choir boy is curious about the following: " I'm working with a group of people who are seriously considering writing a nifty application that would, among other things, allow those of us who want to use Linux in the corporate world to be able to interact with those people who simply insist on using Microsloth products (such as Outlook). We're considering a bunch of options, Java being one of them. My question is... is the JDK 1.2 being ported to Linux?"

Trevor wrote to let us all know that Filaments is ready for download. For those you who are unfamiliar with Filaments, it is a library package that can be used to create architecture-independent parallel programs-that is, programs that are portable and efficient across different parallel machines. Filaments can be used directly as a subroutine library to write parallel programs, but it is most useful as the target of a parallelizing compiler. Click below for the full release annoucement. Filaments version 1.0 is now freely available and can be downloaded on the web at http://www.cs.uga.edu/~dkl/filaments/dist.html or via the the University of Georgia CS Department anonymous FTP server at ftp://ftp.cs.uga.edu/pub/filaments.

The current distribution runs on the following (homogeneous) architectures:

• cluster of Sparcs running Solaris,
• cluster of PCs running Solaris,
• cluster of PCs running Linux,
• SPARC/Solaris symmetric multiprocessor, and
• SGI/Irix symmetric multiprocessor.

The distribution comes with extensive documentation (a programmer's manual plus four other technical papers) and eight sample application kernels.

Filaments is a library package that can be used to create architecture-independent parallel programs-that is, programs that are portable and efficient across different parallel machines. Filaments can be used directly as a subroutine library to write parallel programs, but it is most useful as the target of a parallelizing compiler.

The package uses a carefully designed API along with machine-specific runtime libraries and preprocessing that allow programs to run unchanged on both shared- and distributed-memory machines. Most importantly, applications programmed in Filaments run efficiently, achieving a speedup of over 4 on 8 processors or nodes in almost all tests that have been performed.

Any questions should be directed to filaments@cs.uga.edu.

Trevor has written up a review of ORA's Linux Device Drivers. Like Linux Application Development this is a pretty important book. We all know about getting drivers written, and getting the hardware to work-now learn about how to be better at doing that. Read below for more. Linux Device Drivers author Alessandro Rubini pages publisher O'Reilly & Associates rating 8/10 reviewer trevor@mindspring.com ISBN summary REVIEW: Linux Device Drivers Alessandro Rubini O'Reilly & Associates, Inc.

Nutshell
Review:
Rating: 8/10 trevor@mindspring.com The Scenario

Though written for linux programmers working on device drivers, Linux Device Drivers by Alessandro Rubini also serves as a tour of the kernel for C programmers interested in the design decisions that give us modern linux. For anyone who is undertaking the process of creating a linux driver from scratch, Mr. Rubini has taken the disparate source files involved and created a coherent mosaic of reference which eases the path from idea to implementation. As a result of Mr. Rubini's well structured book, first time driver programmers will save hours of hand tracing code. The code examples are clearly explained and each chapter ends with a reference section to be quickly accessed while programming. This book is current through 2.1.43 and it clearly notes where code changes are necessary in moving from 2.0.x to 2.1.x.

What's Bad?

As with any traditional book on linux, Linux Device Drivers will eventually be out of date for programmers working with the most current linux source.

What's Good?

Chapters 1 through 8 cover the basics of how the kernel loads and unloads modules. It begins with a simple "hello world, I'm a module" example and moves on to more complex examples. This section does not require the use of any special hardware as it implements a memory "software device" which turns out to be handy for other programming tasks. The book's FTP site has each code sample available so no retyping is necessary. For programmers who can do snazzy tricks with data structures, but are new (or rusty) with lower level hardware programming, chapter 8 is a clear and quick (re)introduction to the issues. Chapter 9 introduces the hairy art of interrupt handling and steps through the pitfalls of race conditions and other such monsters.

The second section, Chapters 10 through 15, can be treated as stand alone works on the topics of kerneld, block drivers, mmap and DMA, network devices, and a short overview of peripheral buses. Depending on your programming goals, these chapters may or may not be immediately useful. However, the reference sections at the end of each chapter can help identify where driver problems originate. Each chapter is recommended reading, but covering them all in one sitting is a sure way to overflow your buffer.

The final two chapters are on the topics of the physical layout of the kernel source and recent developments in the experimental line of kernels. The first chapter in this section serves as a boot to shutdown guide to which source handles different kernel operations. For those who need to know (or are simply interested) in the how linux handles the differences in various architectures, this chapter is a good spring board for the necessary code diving. The last chapter of the book, Recent Developments, details where the linux community of kernel programmers seems to be headed. Though there is no replacement for subscribing to the relevant lists and reading the newsgroups, this chapter can bring those new to open source development up to speed.

So What's In It For Me?

Linux Device Drivers maintains the high standard set by other linux related books published by O'Reilly & Associates. Alessandro Rubini has created a solid guide to the tasks and ideas of the linux kernel. It is a fine addition to the bookshelves of linux users and driver writers alike.

Pick this book up at Amazon.

Table of Contents

1. An Introduction to the Linux Kernel
2. Building and Running Modules
3. Char Drivers
4. Debugging Techniques
5. Enhanced Char Driver Operations
6. Flow of Time
7. Getting Hold of Memory
8. Hardware Management
9. Interrupt Handling
10. Judicious Use of Data Types
11. Kerneld and Advanced Modularization
12. Loading Block Drivers
13. MMAP and DMA
14. Network Drivers
15. Overview of Peripheral Buses
16. Physical Layout of the Kernel Source
17. Recent Developments

Trevor has written up a review of ORA's Linux Device Drivers. Like Linux Application Development this is a pretty important book. We all know about getting drivers written, and getting the hardware to work-now learn about how to be better at doing that. Read below for more. Linux Device Drivers author Alessandro Rubini pages publisher O'Reilly & Associates rating 8/10 reviewer trevor@mindspring.com ISBN summary REVIEW: Linux Device Drivers Alessandro Rubini O'Reilly & Associates, Inc.

Nutshell
Review:
Rating: 8/10 trevor@mindspring.com The Scenario

Though written for linux programmers working on device drivers, Linux Device Drivers by Alessandro Rubini also serves as a tour of the kernel for C programmers interested in the design decisions that give us modern linux. For anyone who is undertaking the process of creating a linux driver from scratch, Mr. Rubini has taken the disparate source files involved and created a coherent mosaic of reference which eases the path from idea to implementation. As a result of Mr. Rubini's well structured book, first time driver programmers will save hours of hand tracing code. The code examples are clearly explained and each chapter ends with a reference section to be quickly accessed while programming. This book is current through 2.1.43 and it clearly notes where code changes are necessary in moving from 2.0.x to 2.1.x.

What's Bad?

As with any traditional book on linux, Linux Device Drivers will eventually be out of date for programmers working with the most current linux source.

What's Good?

Chapters 1 through 8 cover the basics of how the kernel loads and unloads modules. It begins with a simple "hello world, I'm a module" example and moves on to more complex examples. This section does not require the use of any special hardware as it implements a memory "software device" which turns out to be handy for other programming tasks. The book's FTP site has each code sample available so no retyping is necessary. For programmers who can do snazzy tricks with data structures, but are new (or rusty) with lower level hardware programming, chapter 8 is a clear and quick (re)introduction to the issues. Chapter 9 introduces the hairy art of interrupt handling and steps through the pitfalls of race conditions and other such monsters.

The second section, Chapters 10 through 15, can be treated as stand alone works on the topics of kerneld, block drivers, mmap and DMA, network devices, and a short overview of peripheral buses. Depending on your programming goals, these chapters may or may not be immediately useful. However, the reference sections at the end of each chapter can help identify where driver problems originate. Each chapter is recommended reading, but covering them all in one sitting is a sure way to overflow your buffer.

The final two chapters are on the topics of the physical layout of the kernel source and recent developments in the experimental line of kernels. The first chapter in this section serves as a boot to shutdown guide to which source handles different kernel operations. For those who need to know (or are simply interested) in the how linux handles the differences in various architectures, this chapter is a good spring board for the necessary code diving. The last chapter of the book, Recent Developments, details where the linux community of kernel programmers seems to be headed. Though there is no replacement for subscribing to the relevant lists and reading the newsgroups, this chapter can bring those new to open source development up to speed.

So What's In It For Me?

Linux Device Drivers maintains the high standard set by other linux related books published by O'Reilly & Associates. Alessandro Rubini has created a solid guide to the tasks and ideas of the linux kernel. It is a fine addition to the bookshelves of linux users and driver writers alike.

Pick this book up at Amazon.

Table of Contents

1. An Introduction to the Linux Kernel
2. Building and Running Modules
3. Char Drivers
4. Debugging Techniques
5. Enhanced Char Driver Operations
6. Flow of Time
7. Getting Hold of Memory
8. Hardware Management
9. Interrupt Handling
10. Judicious Use of Data Types
11. Kerneld and Advanced Modularization
12. Loading Block Drivers
13. MMAP and DMA
14. Network Drivers
15. Overview of Peripheral Buses
16. Physical Layout of the Kernel Source
17. Recent Developments

Todd Lewis writes... "I am pleased to announce the release of Version 1.0 of the GNOME Frequently Asked Questions file. This marks the first major revision of the GNOME FAQ in several months, but I think that the improvement was well worth the wait."

deathcat writes "This is an article on the eating habits of geeks and prop-heads. I got the link from this really cool newsletter Netsurfer Digest ." Add me to the list of unhealthy nerds. My groceries consist of 4 2 liters of mtn dew, a few microwavable pizzas, crackers, juice, a few cases of beer, M&Ms, chips, macaroni and cheese, and hamburger helper. I figure I've got at least a week to live.

wayne sumter sent us a link to an interesting article about journalism on the net. This one talks about Harry Knowles of Aint it Cool News (the only non computer site I visit every day) as well as Matt Drudge and others. It's interesting stuff, but maybe just to me :)

Brian Daniels writes " NASA's created a Beowulf to investigate the data seized from computer criminals. The article is short on technical detail, but Linux and the cost advantage of Beowulf vs supercomputers is mentioned. One wonders about exaggerations though - does the average computer criminal really have "hundreds of gigabytes of data", and where was he keeping it? "

Lars Larsen writes "Forbes magazine is running this story about the possibility that Russia's early warning system will get confused by Y2K bugs and launch Nuclear weapons at the US. The Pentagon is so concerned about the potential impact of this computer glitch to end all glitches on its former Cold War foe that it recently proposed sharing early warning information. "

joshy writes "Since I got such a good response to my Star/Slinux article, I've decided to start a mailing list to discuss how we could actually build such a system. To subscribe send mail to majordomo@shelbyville.stanford.edu with 'subscribe slinux' in the body of the message. (this is the first time I've set up majordomo so mail me if you have any problems.) "

Joshy has written an excellent piece after going to visit the Xerox PARC. Joshy also talks about what we could learn from the Star, and gives some ideas on how Linux could benefit as well. The following is a feature by Slashdot Reader Joshy

A few weeks ago I went with a friend to the last presentation of the Xerox Star computer. It was quite a fun (and full) presentation and highlighted some of the things that are wrong with today's desktop software industry, and allows me bring up some suggestions on how we can fix it (somewhat).

We left Stanford campus to attend The Final Presentation of the Xerox Star at the Xerox Palo Alto Research Center. PARC is the research center where much of the desktop software industry was pioneered in the mid 70's. We got there a few minutes late because of traffic and had to park at FX PAL, another division of Xerox just down the hill from PARC. It still amazes me how much traffic exists on a few miles of back roads in Palo Alto. Presentations at the Pake Auditorium are not usually full, but this one had even filled up the overflow room. We ended up standing outside a second overflow room and watched the proceedings on a closed circuit TV through an open door. What we saw amazed us.

The Star computer was very much ahead of it's time for 1981. It was the successor to the Alto, which was the in house computer designed as a research project at PARC in the late 70's. The hardware consisted of several custom boards, each about 18 inches long and 12 inches wide. The Star had a heavy 8 megabyte (if I remember correctly) hard-drive that was extremely heavy (the guy just about got a hernia picking it up), and 1 megabyte of RAM (an astronomical amount of memory that was still doubled by my first 286). It had on board ethernet that ran at 10 MHz. Originally the Star was to have 20 MHz ethernet but a 10MHz clock chip was small enough to let the ethernet controller fit onto a single board, something which all other commercial ethernet vendors had failed to achieve. (so that's why ethernet runs at 10 MHz!) The keyboard looked like a standard 88 key keyboard with two additional sets of function keys, one on the left side of the main keys, and one above. The left set had names like copy, paste, and properties, while the top set was application specific (more on those later). The mouse had two buttons because research had shown that one was too few and three was too many. One of the presenters joked that the Macintosh also has two buttons on it's mouse, it's just that one of them is on the keyboard.

While the hardware was pretty advanced (it ran as fast as a recent PDP but fit under your desk instead of replacing your fridge) the truly amazing things were in the software. The Star was completely designed to be easy to use by a business professional and ready to run in a networked environment. It had printing, email, RPC (remote procedure calls), a networked file-system, and a complete yet simple desktop environment.

First of all, there was no menu bar. Actually, there was a small pop-up menu with a few oft-used commands that they weren't able to get rid of, but the presenter said that most users never knew they were there. All interactions were done either with direct manipulation, possibly in conjunction with function keys, or with a pop-up window. A user could create a multimedia document (images, text, colors, fonts) using less than 12 different commands. To copy text the user would simply select the text using the mouse and then hit the copy function key. To make some text bold the user would select text and then hit the properties key. A window with a list of properties would pop up, from which the user could change any attribute of the currently selected text. (This is like the context sensitive right menu button in Word, only you don't have to hold the button down.) To move files around or print the user would drag a document from the desktop into a file cabinet or onto a printer icon. If any extra information was needed, a dialog box would pop up asking for it.

To do more complicated things, things that couldn't be done using direct manipulation or with menus, the Star used keyboard mapping. To see what the keys were, the user could hit the 'keyboard' button and see a mini-version of keyboard on-screen, showing what each key did. This mini-keyboard could be used to type in symbols, foreign character sets (like Greek or Spanish), or math equations. It could even be used for Japanese. The user could use the mouse to press a mapped button in the window or just press the key directly. This let the user learn which keys he or she used a lot.

The Star wasn't perfect though. It had a few flaws that kept it back and let it be killed by the IBM PC a year later. With networking, email, windows, and wysiwyg wordprocessing; the Star was truly ahead of it's time. (Despite all of that, the men behind it still felt that it was under powered. It was usable but not zippy. Perhaps with a year or two of advances it would have been really fast.) The system was completely proprietary and not open at all. There was no third party hardware or software. And finally it was too expensive. It may have been many times better than the IBM PC, but for many managers looking to keep down the bottom line, that wasn't the issue.

Still, with all of these problems and it's ancient hardware, it is still better designed than much of what we have today. Apple caught up to PARC's research only 10 years late. Microsoft took 15 years. And they still got things wrong. No word processor should require a Pentium processor and 100 megs of disk space. Today computers are 1000 times faster, have 1000 times more storage (though only 10 times faster I/O), but does it have 1000 times better software? (the audience burst out laughing when one of the presenters facetiously suggested this).

Software has improved tremendously and allowed large productivity increases within specialized areas (like photo editing and page layout) but hasn't really helped out the general office user. We are still using arcane and bloated wordprocessors, slow spreadsheets, and having great trouble getting the printer to use that bottom paper tray. Why are things so bad?

We can try to blame greedy software manufacturers by saying that they promote buggy software which requires tech support and constant upgrades, but this is only part of the problem. The real problem is the lack of good User Centric design (I am using the term User Centric design instead of User Interface design because the issue isn't always about what the user sees on the screen). Too many pieces of our computers were designed to quickly or for alternative purposes and then redirected. It's often because the programmers were forced ship something before it's ready. Just look at any version of Netscape since 1.1. Sometimes I do wonder if the companies actually intend to make buggy software though. (no need to mention any names. :) No matter. We are stuck in our rut now and have to find a way out of it.

So this brings me to the second part of my essay. What do we do about it?

What I am about to propose is not a general solution. It is not meant for servers or workstations or pre-press operators. It is for the general office worker who needs to type reports, calculate spreadsheets, answer email, and print things. (This would probably also be true of most college students.) What I am proposing is a simple prefab version of everyone's favorite alternative operating system. A consolidation of protocols and applications to create something that my mom could use and not worry about it breaking. The office appliance.

Larry Ellison was on the right track when he proposed the Network Computer. He had two problems though. First, he didn't foresee the sub-1000$ computer. No one is going to buy a 700$ NC when they can get a fully loaded Pentium for the same price. Second, he and Scott McNealy assumed that they could make loads of money off of writing new software in Java for these NCs. As simple as these things are supposed to be to use, they are still computers. Computers are complicated things that need to be designed well. And that takes time. Creating machines with a new operating system, new applications, and server backends -- and doing it all in a two year time frame -- is simply a bad idea. I want a simple word processor, not a buggy one. As simple as the Star was to use, it was based on many years of research and design. You can't reinvent everything in two years and expect it to fly without crashing a lot. Larry discovered this at his lackluster NC demo last year. I love Java as a language and a platform. I do all of my new projects in Java. But there is no reason to suddenly *rewrite* everything in Java.

So how does Linux fit in?

First of all, Linux is not new. It has been around for almost eight years now, and is based on principles designed and tested over the last quarter of a century. It is very stable, very extensible, and very lightweight (at least compared to other desktop operating systems). Xwindows is less so, but still pretty good.

Second, Linux has lots of support. It may be lacking the latest hardware drivers, but we don't need this to run on the latest hardware. Linux also has lots of people who know how to maintain it. Armed with the newsgroups, LDP, and maybe a few O'Reilly books, there are tens of thousands of qualified sysadmins.

Third, Linux is already qualified to be a backend server. (multiuser, multiprocessor, security, networking ... yadda yadda yadda ... world domination)

Fourth, Linux is the only non-Microsoft desktop operating system that is growing in marketshare.

So how does this work?

We need Slinux (Simple Linux) to run reliably, quickly, and easily; all without having to call the sysadmin. The sysadmin is busy keeping the servers running or installing new Slinux boxes. She or he doesn't need to be bothered with questions about printer dialog boxes. So we need to address the issues of

• System installation
• System failure due to preferences
• System failure due to bugs or hardware
• Application preference failures
• Simple applications

System installation:

The sysadmin creates a custom distribution for each Slinux machine using a special tool that takes a default distribution and modifies it to fit the target hardware and target network environment. This custom distribution is then burned onto a CD, accompanied by a boot floppy, and installed on the Slinux machine. CD burners are really cheap and *should* be really easy to use.

System failure due to software preferences:

Each client machine has a harddrive with two partitions. One is for the OS and the other is for user data and backup of system files. In the event that the users manage to really screw up their system by changing software configurations (unlikely as it is, it can still happen. Murphy is not on our side.) they can reinstall by popping one floppy and one CD into the machine and rebooting. This is the CD with the custom distribution of Slinux. The floppy will erase the system partition on the harddrive and then reload the preconfigured OS from the CD. The floppy is only a boot image and a driver for the CD. I realize that reinstalling the OS seems more like a Windows 95 solution, but sometimes it really is the easiest solution, especially if there is no configuration required afterwards. Any changes made by the sysadmin since the CD was made would be loaded from the network.

System failure due to bugs or hardware:

Any buggy software can be upgraded remotely with tools designed for such a task. If users reinstall their OS, then the new software will be automatically reloaded at install time. If hardware fails then it will of course have to be replaced and a new CD burned. This new CD would take into account any configuration changes made for that target machine, both changes from the sysadmin and changes made by the user. This is possible because any changes made to the system files by the user (assuming they are allowed to) are backed up in a special place on the user's data partition. And of course the data partitions should all be backed up remotely by the sysadmin onto tapes.

If the target hardware or environment ever changes, then a new CD is burned using the burning tool that keeps track of system wide distribution and all of the variations for each target. Burning a new CD is a lot of work if you just want to change some rc files, so many changes would be done using remote administration tools. Scripts would be run on each target machine to download any changes made by the sysadmin (the scripts could be started explicitly or periodically using a cronjob).

A nice feature would be programs that monitors system performance and email the sysadmin if it looks like anything is getting flaky.

Application preference failures:

If the user changes a preference in an application that breaks the functionality of the app, then there should be a simple program to save the changes and then revert back to the default settings (either from the network or the local disk).

Most users won't change their settings so this shouldn't be a problem, but many people like to futz with their fonts or window manager backgrounds, and this should be a recourse just in case anything breaks.

The default distribution:

This should be set up with the latest stable version of all software. The sysadmin can then pare it down and tweak it to fit the target environment (using tools designed for this job of course). There would be no extra users, no extra daemons running, and bug fixes to all major packages. This ensures that the distribution is a secure as possible.

Simple applications:

What end-user applications should be on this system? In addition to any custom or site specific apps, there should be a word processor, a spreadsheet, an email application, a *graphical* file manager, and a webbrowser. And there shouldn't be much else! This isn't for the poweruser or even the average Linux user. It's for someone like my mom. She doesn't want lots of apps. She just wants to get her work done and not have the computer break. She can install other apps if she really wants to, but most of the time the computer should just sit there and work.

Word Processor: There are word processors out there for Linux but they are way too complex. We need something simple, or at least something that can be configured to look simple with the extra stuff hidden unless the user really wants it. I'm talking paragraphs, font size and italics. HTML will serve what most people want out of a wordprocessor.

Spreadsheet: I'm not sure what's out there right now, but I know that I've been very happy using Excel 4.0 for Mac 68k (using the Executor emulator. See http://www.ardi.com/). In fact, I think it *still* has too many features, and it still made graphing too hard. Making charts should be very easy, especially for college students doing their chemlabs. Again the important thing is that the sysadmin can configure the default installation.

Email application: As Mozilla progresses I'm hoping that the email app will get better and eventually be as good as Eudora (stable, fast, easy to do filtering).

Web Browser: Mozilla. (Duh!)

File Manager: I think that KDE is coming along pretty well, though it needs to be more configurable (from the sysadmin side). I'd say that several windowmanager/filemanager combinations should be installed and the user can pick which one they want. These all should be preconfigured by the sysadmin using a preconfiguration tool (dotconfig?)

System Services:

We need to decide on protocols for user to user and user to service interaction.

For email we should have both shared spools and IMAP (people should be able to access their mail from home, firewalls be damned!). All mail readers should be mime-capable.

For networking and filesystems we have TCP/IP, NFS, SMTP. I would say we should ignore directory and database services that aren't web based, but that's up to each sysadmin.

Is there a standard for printing? We have postscript for the files, but what about selecting destination printers and trays. These shouldn't require arcane options for lpr. It would be nice if any application could call a small printer program that pops up a dialog box customized for the target computer/environment. Then a user can directly select which printer and what kind of paper they want.

Miscellaneous:

Instructions on how to reset apps or the system should be in a two page manual that is printed out, *laminated*, and sits on the user's desk.

Small shared apps (like games) or large data collections (like desktop backgrounds) could be on an shared NFS drive.

So what do people think? Is this do able? Are there others working on similar projects? I'd like to start a discussion group to put together such a Linux distribution. Also I'd like some name suggestions. 'NC Linux' might give the impression that it is completely dependent on the network or destined for set top boxes. 'iLinux' might get us sued. :) Slinux? Slynux? eLinux? EZLinux?

Joshy has written an excellent piece after going to visit the Xerox PARC. Joshy also talks about what we could learn from the Star, and gives some ideas on how Linux could benefit as well. The following is a feature by Slashdot Reader Joshy

A few weeks ago I went with a friend to the last presentation of the Xerox Star computer. It was quite a fun (and full) presentation and highlighted some of the things that are wrong with today's desktop software industry, and allows me bring up some suggestions on how we can fix it (somewhat).

We left Stanford campus to attend The Final Presentation of the Xerox Star at the Xerox Palo Alto Research Center. PARC is the research center where much of the desktop software industry was pioneered in the mid 70's. We got there a few minutes late because of traffic and had to park at FX PAL, another division of Xerox just down the hill from PARC. It still amazes me how much traffic exists on a few miles of back roads in Palo Alto. Presentations at the Pake Auditorium are not usually full, but this one had even filled up the overflow room. We ended up standing outside a second overflow room and watched the proceedings on a closed circuit TV through an open door. What we saw amazed us.

The Star computer was very much ahead of it's time for 1981. It was the successor to the Alto, which was the in house computer designed as a research project at PARC in the late 70's. The hardware consisted of several custom boards, each about 18 inches long and 12 inches wide. The Star had a heavy 8 megabyte (if I remember correctly) hard-drive that was extremely heavy (the guy just about got a hernia picking it up), and 1 megabyte of RAM (an astronomical amount of memory that was still doubled by my first 286). It had on board ethernet that ran at 10 MHz. Originally the Star was to have 20 MHz ethernet but a 10MHz clock chip was small enough to let the ethernet controller fit onto a single board, something which all other commercial ethernet vendors had failed to achieve. (so that's why ethernet runs at 10 MHz!) The keyboard looked like a standard 88 key keyboard with two additional sets of function keys, one on the left side of the main keys, and one above. The left set had names like copy, paste, and properties, while the top set was application specific (more on those later). The mouse had two buttons because research had shown that one was too few and three was too many. One of the presenters joked that the Macintosh also has two buttons on it's mouse, it's just that one of them is on the keyboard.

While the hardware was pretty advanced (it ran as fast as a recent PDP but fit under your desk instead of replacing your fridge) the truly amazing things were in the software. The Star was completely designed to be easy to use by a business professional and ready to run in a networked environment. It had printing, email, RPC (remote procedure calls), a networked file-system, and a complete yet simple desktop environment.

First of all, there was no menu bar. Actually, there was a small pop-up menu with a few oft-used commands that they weren't able to get rid of, but the presenter said that most users never knew they were there. All interactions were done either with direct manipulation, possibly in conjunction with function keys, or with a pop-up window. A user could create a multimedia document (images, text, colors, fonts) using less than 12 different commands. To copy text the user would simply select the text using the mouse and then hit the copy function key. To make some text bold the user would select text and then hit the properties key. A window with a list of properties would pop up, from which the user could change any attribute of the currently selected text. (This is like the context sensitive right menu button in Word, only you don't have to hold the button down.) To move files around or print the user would drag a document from the desktop into a file cabinet or onto a printer icon. If any extra information was needed, a dialog box would pop up asking for it.

To do more complicated things, things that couldn't be done using direct manipulation or with menus, the Star used keyboard mapping. To see what the keys were, the user could hit the 'keyboard' button and see a mini-version of keyboard on-screen, showing what each key did. This mini-keyboard could be used to type in symbols, foreign character sets (like Greek or Spanish), or math equations. It could even be used for Japanese. The user could use the mouse to press a mapped button in the window or just press the key directly. This let the user learn which keys he or she used a lot.

The Star wasn't perfect though. It had a few flaws that kept it back and let it be killed by the IBM PC a year later. With networking, email, windows, and wysiwyg wordprocessing; the Star was truly ahead of it's time. (Despite all of that, the men behind it still felt that it was under powered. It was usable but not zippy. Perhaps with a year or two of advances it would have been really fast.) The system was completely proprietary and not open at all. There was no third party hardware or software. And finally it was too expensive. It may have been many times better than the IBM PC, but for many managers looking to keep down the bottom line, that wasn't the issue.

Still, with all of these problems and it's ancient hardware, it is still better designed than much of what we have today. Apple caught up to PARC's research only 10 years late. Microsoft took 15 years. And they still got things wrong. No word processor should require a Pentium processor and 100 megs of disk space. Today computers are 1000 times faster, have 1000 times more storage (though only 10 times faster I/O), but does it have 1000 times better software? (the audience burst out laughing when one of the presenters facetiously suggested this).

Software has improved tremendously and allowed large productivity increases within specialized areas (like photo editing and page layout) but hasn't really helped out the general office user. We are still using arcane and bloated wordprocessors, slow spreadsheets, and having great trouble getting the printer to use that bottom paper tray. Why are things so bad?

We can try to blame greedy software manufacturers by saying that they promote buggy software which requires tech support and constant upgrades, but this is only part of the problem. The real problem is the lack of good User Centric design (I am using the term User Centric design instead of User Interface design because the issue isn't always about what the user sees on the screen). Too many pieces of our computers were designed to quickly or for alternative purposes and then redirected. It's often because the programmers were forced ship something before it's ready. Just look at any version of Netscape since 1.1. Sometimes I do wonder if the companies actually intend to make buggy software though. (no need to mention any names. :) No matter. We are stuck in our rut now and have to find a way out of it.

So this brings me to the second part of my essay. What do we do about it?

What I am about to propose is not a general solution. It is not meant for servers or workstations or pre-press operators. It is for the general office worker who needs to type reports, calculate spreadsheets, answer email, and print things. (This would probably also be true of most college students.) What I am proposing is a simple prefab version of everyone's favorite alternative operating system. A consolidation of protocols and applications to create something that my mom could use and not worry about it breaking. The office appliance.

Larry Ellison was on the right track when he proposed the Network Computer. He had two problems though. First, he didn't foresee the sub-1000$ computer. No one is going to buy a 700$ NC when they can get a fully loaded Pentium for the same price. Second, he and Scott McNealy assumed that they could make loads of money off of writing new software in Java for these NCs. As simple as these things are supposed to be to use, they are still computers. Computers are complicated things that need to be designed well. And that takes time. Creating machines with a new operating system, new applications, and server backends -- and doing it all in a two year time frame -- is simply a bad idea. I want a simple word processor, not a buggy one. As simple as the Star was to use, it was based on many years of research and design. You can't reinvent everything in two years and expect it to fly without crashing a lot. Larry discovered this at his lackluster NC demo last year. I love Java as a language and a platform. I do all of my new projects in Java. But there is no reason to suddenly *rewrite* everything in Java.

So how does Linux fit in?

First of all, Linux is not new. It has been around for almost eight years now, and is based on principles designed and tested over the last quarter of a century. It is very stable, very extensible, and very lightweight (at least compared to other desktop operating systems). Xwindows is less so, but still pretty good.

Second, Linux has lots of support. It may be lacking the latest hardware drivers, but we don't need this to run on the latest hardware. Linux also has lots of people who know how to maintain it. Armed with the newsgroups, LDP, and maybe a few O'Reilly books, there are tens of thousands of qualified sysadmins.

Third, Linux is already qualified to be a backend server. (multiuser, multiprocessor, security, networking ... yadda yadda yadda ... world domination)

Fourth, Linux is the only non-Microsoft desktop operating system that is growing in marketshare.

So how does this work?

We need Slinux (Simple Linux) to run reliably, quickly, and easily; all without having to call the sysadmin. The sysadmin is busy keeping the servers running or installing new Slinux boxes. She or he doesn't need to be bothered with questions about printer dialog boxes. So we need to address the issues of

• System installation
• System failure due to preferences
• System failure due to bugs or hardware
• Application preference failures
• Simple applications

System installation:

The sysadmin creates a custom distribution for each Slinux machine using a special tool that takes a default distribution and modifies it to fit the target hardware and target network environment. This custom distribution is then burned onto a CD, accompanied by a boot floppy, and installed on the Slinux machine. CD burners are really cheap and *should* be really easy to use.

System failure due to software preferences:

Each client machine has a harddrive with two partitions. One is for the OS and the other is for user data and backup of system files. In the event that the users manage to really screw up their system by changing software configurations (unlikely as it is, it can still happen. Murphy is not on our side.) they can reinstall by popping one floppy and one CD into the machine and rebooting. This is the CD with the custom distribution of Slinux. The floppy will erase the system partition on the harddrive and then reload the preconfigured OS from the CD. The floppy is only a boot image and a driver for the CD. I realize that reinstalling the OS seems more like a Windows 95 solution, but sometimes it really is the easiest solution, especially if there is no configuration required afterwards. Any changes made by the sysadmin since the CD was made would be loaded from the network.

System failure due to bugs or hardware:

Any buggy software can be upgraded remotely with tools designed for such a task. If users reinstall their OS, then the new software will be automatically reloaded at install time. If hardware fails then it will of course have to be replaced and a new CD burned. This new CD would take into account any configuration changes made for that target machine, both changes from the sysadmin and changes made by the user. This is possible because any changes made to the system files by the user (assuming they are allowed to) are backed up in a special place on the user's data partition. And of course the data partitions should all be backed up remotely by the sysadmin onto tapes.

If the target hardware or environment ever changes, then a new CD is burned using the burning tool that keeps track of system wide distribution and all of the variations for each target. Burning a new CD is a lot of work if you just want to change some rc files, so many changes would be done using remote administration tools. Scripts would be run on each target machine to download any changes made by the sysadmin (the scripts could be started explicitly or periodically using a cronjob).

A nice feature would be programs that monitors system performance and email the sysadmin if it looks like anything is getting flaky.

Application preference failures:

If the user changes a preference in an application that breaks the functionality of the app, then there should be a simple program to save the changes and then revert back to the default settings (either from the network or the local disk).

Most users won't change their settings so this shouldn't be a problem, but many people like to futz with their fonts or window manager backgrounds, and this should be a recourse just in case anything breaks.

The default distribution:

This should be set up with the latest stable version of all software. The sysadmin can then pare it down and tweak it to fit the target environment (using tools designed for this job of course). There would be no extra users, no extra daemons running, and bug fixes to all major packages. This ensures that the distribution is a secure as possible.

Simple applications:

What end-user applications should be on this system? In addition to any custom or site specific apps, there should be a word processor, a spreadsheet, an email application, a *graphical* file manager, and a webbrowser. And there shouldn't be much else! This isn't for the poweruser or even the average Linux user. It's for someone like my mom. She doesn't want lots of apps. She just wants to get her work done and not have the computer break. She can install other apps if she really wants to, but most of the time the computer should just sit there and work.

Word Processor: There are word processors out there for Linux but they are way too complex. We need something simple, or at least something that can be configured to look simple with the extra stuff hidden unless the user really wants it. I'm talking paragraphs, font size and italics. HTML will serve what most people want out of a wordprocessor.

Spreadsheet: I'm not sure what's out there right now, but I know that I've been very happy using Excel 4.0 for Mac 68k (using the Executor emulator. See http://www.ardi.com/). In fact, I think it *still* has too many features, and it still made graphing too hard. Making charts should be very easy, especially for college students doing their chemlabs. Again the important thing is that the sysadmin can configure the default installation.

Email application: As Mozilla progresses I'm hoping that the email app will get better and eventually be as good as Eudora (stable, fast, easy to do filtering).

Web Browser: Mozilla. (Duh!)

File Manager: I think that KDE is coming along pretty well, though it needs to be more configurable (from the sysadmin side). I'd say that several windowmanager/filemanager combinations should be installed and the user can pick which one they want. These all should be preconfigured by the sysadmin using a preconfiguration tool (dotconfig?)

System Services:

We need to decide on protocols for user to user and user to service interaction.

For email we should have both shared spools and IMAP (people should be able to access their mail from home, firewalls be damned!). All mail readers should be mime-capable.

For networking and filesystems we have TCP/IP, NFS, SMTP. I would say we should ignore directory and database services that aren't web based, but that's up to each sysadmin.

Is there a standard for printing? We have postscript for the files, but what about selecting destination printers and trays. These shouldn't require arcane options for lpr. It would be nice if any application could call a small printer program that pops up a dialog box customized for the target computer/environment. Then a user can directly select which printer and what kind of paper they want.

Miscellaneous:

Instructions on how to reset apps or the system should be in a two page manual that is printed out, *laminated*, and sits on the user's desk.

Small shared apps (like games) or large data collections (like desktop backgrounds) could be on an shared NFS drive.

So what do people think? Is this do able? Are there others working on similar projects? I'd like to start a discussion group to put together such a Linux distribution. Also I'd like some name suggestions. 'NC Linux' might give the impression that it is completely dependent on the network or destined for set top boxes. 'iLinux' might get us sued. :) Slinux? Slynux? eLinux? EZLinux?

Geoff Corey writes "CMPNET is doing a series of articles on open source. This ought to stir emotions . . . link"

Allright we've got a new mysql running. Hopefully things will be stable. Ooo, and older articles will be 'archived' soon (comments remaining intact). It's the last major code change before the Test Site. OK first off steven sent us a link to a Fortune 500 open source stuff Dr.Claw wrote in to tell us that Debian has gone into deep freeze on 2.0. Oh, and we were mentioned in wired yesterday as part of the whole J*va invaders thing. I didn't intend to make a big deal about it, I just wanted to tell everyone why they can't play Invaders anymore, but 2 hours after I post it I've got a phone call from 'em. Oh well.

Unxmaal writes "This is an interesting article about free software, GNU, etc. A very nice read, and an important one. (The rest of the Bad-Subjects archive is great, too!)"

Lars Larsen writes "Novell has released the results of a study that shows that spam costs British and Irish businesses more than US$8 billion annually. They claim their email software will solve the spam problem but the really amusing part is that Novell's mail servers are open relays. You can read more about it here. "

Lars Larsen wrote in with this link and says "You can store up to 20 minutes of video to its 260 MB PC card hard disk. The video is captured at 30 frames per second at a resolution of 352 X 240. It also captures up to 3,000 still images (at 704 X 480 resolution) in JPEG format. It also has power zoom and a 1.8 inch color LCD viewfinder. " I guess it's only a matter of bandwidth before we have real time mpeg video streaming now, right?

Both MAE East (Washington) and MAE West (Silicon Valley) have been undergoing greater then normal congestion and packet loss, accordingto techs. Mindspring has been at the forefront of identifying the problem, but as of yet, no one is quite sure this is happening. This congestion and packet loss has been leading to slower response times from many ISP. Both MAE here are operated by Worldcom.