Lucent brews Inferno

New combination language/OS has designs on network communications

The same folks that brought us Unix and C are promising something even better for network communication: Inferno, a networkable OS that runs on a variety of platforms ranging from palmtop organizers to mission-critical telephone switches. In May, Lucent Technologies made the first public announcement about the technology. In early September, Lucent announced the distribution of a free early version of Inferno for Plan 9, Windows 95, Windows NT 3.5 and 4.0, Irix 5.3, and Solaris 2.5. This software, which can be downloaded from Lucent's Web site at http://inferno.lucent.com/inferno, contains the Inferno operating system, the Limbo programming language, a developer's toolkit, documentation and sample applications, including a World Wide Web browser and an electronic mail package. A commercial version of Inferno is due by the end of 1996.

Inferno has been compared to Java by many in the press. Lucent, however, says Inferno will not necessarily replace Java, and will be able to work with Java to simplify network computing.

At this point, both technologies are a combination of language and OS. Inferno was designed from the ground up as an OS, whereas JavaOS was designed after the programming language. Some feel that this gives Inferno an edge since many of the functions such as security are built right into the operating system at the most basic level.

Comparison between Inferno/Limbo and JavaOS/Java

Both technologies employ a virtual machine, support threads, and

are designed to be platform-independent.

Inferno/Limbo:

JavaOS/Java:

Security

Built-in authentication and encryption at OS level, but not automatic machine protection security.

Machine protection security is built-in. Encryption is being added.

Resource access

One file system accesses everything from data to network resources.

File system accesses local data. Network data must be accessed through the server.

Minimum Sized Machine to Run applications

512 kilobytes of RAM and 512 kilobytes of ROM.

512 kilobytes of ROM and 128 kilobytes of RAM

Object-oriented

No

Yes

Virtual Machine

Dis

Java Virtual Machine

Comparing the two environments, Peter Bernstein, president of Infonautics Consulting in Ramsey, NJ, noted, "I am not sure this is an apples-to-apples comparison. Inferno does have a full-blown operating system and a virtual machine and a protocol stack, and in a lot of respects is something Java would like to be when it grows up. It is also a complement to Java because you will be able to run Java applications within Inferno. There is extraordinary value if Lucent is successful in positioning Java with the telephone companies as a platform for allowing the reality of write it once and play it anywhere on anything."

"Inferno is a unique network operating system that adapts to whatever you plug into it -- from a high-end workstation to an inexpensive hand-held device," noted Dennis Ritchie, one of the developers of C and currently head of system software research at Lucent. "Imagine the ease and flexibility of a world in which you can get your e-mail virtually anywhere, from any machine -- on your PC at the office, from a screen phone in an airport, on your TV at home, or on a hotel room TV if you are traveling."

Inferno was developed by Rob Pike, Phil Winterbottom, and Sean Dorward of the Bell Labs Computing Science Research Center -- the same place that Unix, C, and C++ were invented.

Optimized for distributed network applications

Although JavaOS is designed to act as a portable network operating system, Winterbottom points out that it is not yet optimized for large-scale server applications. "An operating system implies you have things like uniform file permission, importing and exporting of name spaces, and process management," he noted. "There is a whole set of network services that are not part of the Java runtime environment. JavaOS is designed to run Java on small clients. The Inferno OS is designed to be part of a network infrastructure. This means that where Java applications currently seem client-oriented, we are more focused on being able to use resources in the network to distributed computers. We think of this more as a peer-to-peer communication where applications are actually spread over several networks."

One of the most significant differences between Inferno and other operating systems such as JavaOS is the way in which Inferno presents network resources to an application. In Inferno, every resource, whether it is a database or a distant computer, is accessed as if it were a file in a traditional hierarchical file system (like Unix). (Inferno's different services are joined into a single private hierarchical name space. The Styx communications protocol is used to access all local and external resources. Since it can run on top of TCP/IP, PPP, and ATM, Styx can be deployed easily across existing networks.) In Java, Internet resources must be accessed indirectly by making a call to the server.

"It turns out that the network interface is a file tree and the graphics interface is a file tree," Winterbottom explained. "You can have an application access the graphics device of a remote screen. This arises from the Plan 9 work. You are building an application over a higher level of abstraction. Things like naming and security are decoupled from the applications. All of these needs are met by the operating system. The design is such that the structure of the system gives you guidance on how to build applications."

Security: To trust or not to trust?

There are two kinds of security involved in network programming systems: machine protection security and encryption security. The first kind of security protects your machine against a malicious attack, while the second is used to transmit secure data and authenticate resources. Inferno has encryption security built-in, but does not have any way of automatically controlling dangerous applets. Java has built-in machine protection security, and is adding encryption support now.

In Inferno, the encryption is built into the heart of the operating system. "The fundamental difference is that Java has a secure API for a specific application," Winterbottom explained. "We have one set of APIs for doing secure things, and those secure mechanisms are built into the foundation of the system. To use them or not use them is moot."

But Inferno does not have a way of automatically preventing rogue programs from attacking your machine. Instead, it relies on a system of trust of some authenticating authority that is believed to be reliable. An administrator must sign secure resources to guarantee their validity and behavior.

This approach works fine when there are only a few trusted programmers creating applets. But what happens when you have millions of programmers creating applets that are distributed around the world? Arthur van Hoff, one of the developers of Java and the current CTO of Marimba Inc., pointed out, "Security through encryption at some point involves trust, and that is really hard. It works if I can trust Microsoft, but if I visit a Web page from a student in Pakistan, do I trust it? If you build a language that has security only through encryption -- that is a losing battle.

"Who will be that certification authority?" van Hoff asked. "Do you trust everyone with a drivers license to drive your car? That works great if there are 10 drivers in the world, but...it breaks down when there are millions and millions of drivers because the [department of motor vehicles] cannot check everyone really thoroughly.

"A certification authority works great with a thousand software developers," van Hoff said, "but not 100 million -- and I want a world with 100 million Java programmers."

With Java, the encryption security APIs are in the process of being developed, but this does not mean they came as an afterthought. Marianne Mueller, a JavaSoft security expert, notes that security has been important to Java from its inception. "Incremental development is not the same as tacking it on after the fact. It is a reality of software that incremental development is the way things get built. I believe that doing small, incremental releases that stick to API compatibility is a sensible development path, and I would not describe it as tacking things on."

Encryption security was purposefully left out in the beginning, noted van Hoff, so that it would be easier to ship Java tools internationally without running into export restrictions on encryption. "Java is supposed to be a universal language, and to get universal export rights is hard. That is why we did not [employ] encryption in the first place."

At this point, security of Java applets is controlled by limiting the resources they can access, but that will change when digital signatures are incorporated into Java. Mueller explained, "Applets in general are not allowed to read and write to the local machine and the Net. With digital signatures, we will be able to loosen those restrictions, so applets can have unlimited authority. We are working on a more advanced architecture to support flexible security policies."

Comparing Limbo to Java

To relate the Java programming language to the Inferno environment, you must look at Lucent's Limbo language to make an apples-to-apples comparison. One advantage of Limbo is that concurrency and communication are built into the language. A "channel" is used to connect Limbo applications on the same machine or across a network. The channel transports its data in a machine-independent format, which enables complex data structures to be passed around or attached to files.

Winterbottom said Lucent engineers spent a lot of time trying to optimize the garbage collection so that it could work on small clients. "When we started out, we were interested in working with very thin clients," he said. "We thought the most interesting potential for Web stuff was to make it ubiquitous. If you have a garbage collector you use an enormous amount of time doing garbage collection, or you use a lot of memory."

Limbo connects all of the resources to the garbage collector, so if an application dies, the OS does not have to keep track of and delete the memory reserved for it. This adds a little overhead in tracking the reference counts, but reduces the amount of memory required on the system. The garbage collector has constant overhead, so it does not interfere with real-time constraints.

"We can run an interesting system in about a megabyte of memory using our standalone kernel," Winterbottom said. "You would want about half a megabyte of ROM, and half a megabyte of RAM."

Another aspect of Limbo is that it is not object-oriented like C++ or Java. To provide the functionality you get from object systems, Limbo relies on a rich set of basic data types such as lists, strings, and tuples (arrays of numbers) built into the language. Limbo programs are written as a set of modules. At runtime these modules export their interfaces to whatever resource is available for display or control. For example, a codec for playing MPEG video would be written as a Limbo module, and called when someone wanted to play a video. These modules are completely portable between Limbo machines.

Like Java, Limbo has its own virtual machine, which is called Dis. Dis is based on a memory-to-memory architecture that makes it easy to translate to native operating systems. The just-in-time compiler for Dis is small. The implementation on a 386 PC, for example, is only about 1,300 lines of code. It is also quite fast for a just-in-time compiler. Winterbottom said that the Limbo JIT compilers get performance between 1.5 and 3 times slower than compiled C code.

Deploying Inferno in the real world

One Australian government programmer who asked not to be identified said that his group has been evaluating distributed programming languages like Java and TCL/TK, but they are not happy with any at this point due to a number of concerns, including security, stability, support, and performance. They have a Limbo interpreter that they are using to test the features of the Limbo language, and to test the feasibility of translations from Java and other languages.

"We anticipate Inferno being our principal development and deployment environment," the programmer noted, "but have to formally verify its acceptability over the next few months. We believe Inferno provides a suitable environment for us because of its portability, simplicity, strengths in distributed computing, and built-in security/encryption features. It is a complete environment and not simply a language."

He sees his group using Inferno to create distributed computing applications that provide government interfaces to international trade, financial instruments, and knowledge repositories.

Lucent has close connections with the telephone industry, which it has been supplying with switches and other equipment for several decades. But getting a large body of programmers to adopt Inferno and Limbo, as Sun has done with Java, may prove difficult.

"Sun has hitched Java to the success of the Internet," noted David Smith, Research Director at The Gartner Group. "The Lucent folks are very reluctant to glom onto the Internet. They seem rooted back in the excitement of interactive TV that has not gone very far in those couple of years. It is very much a telephone-company mentality of 'we have the best technology,' but that is not necessarily what is going to win."

1 2 Page 1
Page 1 of 2