Slashdot Mirror

Second, the alternative to C++ for system programming is C, which is from the 1960's, even earlier.

Presumably you mean that its philosophy comes from the '60's, not that the language itself comes from the '60's, given that Dennis Ritchie indicates that this version of the original B Reference Manual is dated 1972, and C is a descendant of B, so C is from the '70's.

Lucent did this about, what, a year ago? Read here. Nortel has already done this as well. Here's the Nortel link.

Optical switching is really cool, don't get me wrong! The slowest link in any big telco network is the switching equipment. How are you going to resolve Nortel's new 2.4Terabit pipes with OC-3 or OC-12 switching technology? Guess what, not happening.

Have a read about what Lucent and Nortel are doing...very cool stuff.

Thanks for the explanation. I 've found a picture of SCALPEL (the competing Bell Labs effort) here. As an electron spectroscopist in a previous life, I found your reply to be the most informative article in this topic so far.

That said, a couple of questions:

• What's their electron source? Surely not a heated filament, as you imply. Thermal noise from even a low amperage filament overwhelms space-charge effects, e.g., about 1.5 eV for heating v.s. about 0.5 eV for space-charge in a microamp beam. Are they using field-emission sources?
• Secondly, is the limitation on "brightness" a space-charge/energy effect or simply low-flux sources?

Overview of EBL system

There is no X support at all. Moreover, there's no ML support at all! Please W3C change the name.
--

I think the reason why unix hasn't changed much in the last 20 years is because of backward compability. But there is a major development: plan9, by the people that designed unix. It deals with many of the areas that are badly designed in Unix. Read the FAQ to learn more....

I agree with you that it's a pain to have to do a cast on something the compiler ought to have figured out can't cause a type safety violation. Type polymorphism (ie, templates) is definitely the biggest thing missing from Java. Fortunately, they're adding it (see?). In fact, there's already an compiler that will do it- it's just not Sun-blessed. (But the .class files that GJ spits out are ostensibly bytecode-compatible with regular java, so no special JVM is required to run them.)

map > word_positions;
string word;
while (cin)
{
cin >> word;
word_positions[word].push_back((int)cin.tellg() - word.size());
}

Heres a java object to do this.

import java.io.*;
import java.util.*;
public class TokenizeStdin extends
BufferedInputStream
{
TokenizeStdin( Hashtable wordMap ) throws IOException
{
super( System.in );
StreamTokenizer strTok = new StreamTokenizer( this );
while( strTok.nextToken() != StreamTokenizer.TT_EOF )
{
if( !wordMap.containsKey( strTok.sval ) )
wordMap.put( strTok.sval, new Vector() );
( ( Vector )wordMap.get( strTok.sval ) ).addElement( new Integer( pos - strTok.sval.length() ) );
}
}
}
This in not a snippet! This is the whole shebang. If the above C++ comment were expanded to make it compile ( the java version will compile as is ) it would be as long as my java version. I agree that the Java version is not as pretty, but that is mostly due to the fact that the java container classes have not reached the level of maturity that the Standard C++ containers have, yet. But remember that for the first 8 - 10 years of C++, templates were not available, and there were no Standard C++ containers. People are working on adding templates to java. See gjc. Once this has reached maturity, good templatized container classes can't be far behind.

Stroustrup works at Bell Labs Computing Sciences Research Center in Murray Hill, NJ. Other past and present inhabitants of CSRC include Dennis Ritchie, Brian Kernighan, Ken Thompson, Rob Pike, Al Aho (also Sethi and Ullman) and pretty much the rest of the pantheon. Stroustrup is actually not one of the most revered people there, scary though that may seem.

Bell Labs Computing Sciences Research

Bell Labs Index

Stroustrup works at Bell Labs Computing Sciences Research Center in Murray Hill, NJ. Other past and present inhabitants of CSRC include Dennis Ritchie, Brian Kernighan, Ken Thompson, Rob Pike, Al Aho (also Sethi and Ullman) and pretty much the rest of the pantheon. Stroustrup is actually not one of the most revered people there, scary though that may seem.

Bell Labs Computing Sciences Research

Bell Labs Index

in.telnetd: ALL: spawn (cat /usr/local/share/audio/telnet.au > /dev/audio) &

A good way to make those sounds is the web text to speech converter.

Broccolist

# wait for job complete would probably fall into Pike's

• Retrofitting Quality of Service into a Time-Sharing Operating System
• Quality of Service Support for Legacy Applications
• Disk Scheduling with Quality of Service Guarantees

Noel

RootPrompt.org -- Nothing but Unix

• Retrofitting Quality of Service into a Time-Sharing Operating System
• Quality of Service Support for Legacy Applications
• Disk Scheduling with Quality of Service Guarantees

Noel

RootPrompt.org -- Nothing but Unix

• Retrofitting Quality of Service into a Time-Sharing Operating System
• Quality of Service Support for Legacy Applications
• Disk Scheduling with Quality of Service Guarantees

Noel

RootPrompt.org -- Nothing but Unix

I'd say that the having every class extend from Object is a feature of java, not a bug.

But i do agree that having to downcast all of the time is stupid and inefficient. THat's why there were three research projects going on in parallel to add Generic (Polymorphic) Types to Java. One of them was done here at MIT, but it seems that people tend to like Bell Labs' GJ better (I can understand why)

Basically, think Templates, but better. C:)

The closest thing to what is being described in terms of a non-experimental/non-academic language seems to me to be either Haskell or BETA. Haskell is free and available for Linux, Beta is also free and comes with an extensive development environment (called Mjølner) and it is also available for Linux (yay!). Both of these langauges are very interesting.

Most of the other systems that implement new ideas are experimental and not available AFAIK, but papers describing them are available.

Some good papers to look at are:

• Kim Bruce's Papers: pretty much everything he lists under research is related to this thread.
  
• Luca Cardelli's Papers: most of the stuff that relates is under Types and Semantics, but the other catagories have worthwhile stuff too.
  
• Phillip Wadler has so many fascinating papers on so many interesting topics that I'm just gonna link to his main page... what else can I do?
  

These are good starting points. For more places to look see my list of language bookmarks , especially under people & projects (or specific languages).

FORTRAN was old when I wrote my first computer programs, many years ago. Even though its popularity has waned, I still know programmers and scientists who write everything in FORTRAN.

I'm sure that some new language will eventually replace C and C++. That day is likely to be decades away. People forget how long it took for C to become a popular programming language. See Dennis Ritchie's paper on the history of C.

As a side rant, whatever happened to languages that could be completely described in a thin book such as Niklaus Wirth's "Pascal - User Manual and Report" and Kernighan and Ritchie's "The C Programming Language". Too many languages and operating systems have become unmanageable waste dumps of "features".

Sun began when BSD (renamed SunOS by an infant Sun Microsystems)

Depends on when you think infancy ends; SunOS 4.0 was, as I remember, the first release where we called it "SunOS" rather than "Sun UNIX 4.2BSD" (mainly because we figured AT&T might go on one of their rampages against using UNIX for anything that wasn't vanilla unmodified AT&T System V Consider It Standard). It came out somewhere around 1987, at which point Sun was four years old - and had already gone through three major releases of the OS (1.0, 2.0, and 3.0).

4.0 was a heck of a lot more than just BSD; it included a completely new VM system (supported memory-mapped files, isolated the code that dealt with the MMU in a "HAT layer" (for "Hardware Address Translation")) and a dynamic-linking mechanism, built atop mmap(), from which the SVR4 mechanism was derived (the dynamic-linking mechanisms in Linux and {Free,Net,Open}BSD are based on the Sun/SVR4 mechanism). It also included a number of System V-isms (in the kernel as well as userland), and a STREAMS-based tty subsystem.

SVR4 was the result of a deal between AT&T and Sun; the theory was, at the time, that

1. Sun had to have a UNIX that was Genuine System V in order to break into the business world (yes, there was a Sun manager who claimed exactly that, in a meeting I was in; when I asked whether HP would replace the kernel in HP-UX - which I think was BSD-derived, although it had been made SV-compatible and given a largely SV userland - with System V Consider It Standard, he assured me that they were going to do that, although an HP person - admittedly, an engineer, so maybe he was too deep in the trenches to know what the generals were thinking - said he knew nothing of any such plans, and, well, HP was, in any case, one of the founders of the OSF - so much for going completely with SV);
2. Sun plus AT&T could join together and make SPARC+SVR4 the replacement for x86+DOS/Windows (AT&T was going to make SPARC-based machines, but they never got to the product stage)

(I remember Bill Joy stating, at a Sun OS group beer bust, something about how having multiple hardware platforms wasn't necessarily a good idea, and maybe it was time to settle on one platform, by which I rather suspect he meant SPARC. I think my response was something on the order of "the one platform may not end up being yours".)

The intent was to merge the features of SunOS 4.x (both the BSD features not already in System V, and the Sun features such as the new VM system and the dynamic linking mechanism) with System V to produce the One True UNIX. (There were also plans to do, as I remember, an exotic object-oriented blah blah blah operating system as The One True UNIX: The Next Generation, but those plans came to naught.)

Well, shall we say, much of the rest of the UNIX world wasn't exactly delighted by this, hence the OSF, which was going to do their own UNIX (OSF/1, eventually adopted as a mainstream UNIX by the following main members of the OSF: Digital Equipment Corporation, Digital Equipment Corporation, Digital Equipment Corporation, and, err, umm, Digital Equipment Corporation, although I think Intel used a version of OSF/1 in one of their Paragon i860-based supercomputers).

It might be interesting to make a list of the goals of the AT&T/Sun deal, and of the OSF, that either never saw the light of day, or eventually failed (for whatever reason), e.g. OPEN LOOK, OSF/1 as the UNIX for all the OSF members, World Domination By SPARC/SVR4, etc..

For example, the streams interface is, in some ways, superior to the way Linux kernel modules work.

You're comparing apples and frying pans here, in a sense. STREAMS is orthogonal to loadable kernel modules - you can have an OS without LKMs that supports STREAMS (SVR3, SunOS 4.0[.x], older SVR4s), you can have an OS with LKMs that supports STREAMS (SunOS 4.1[.x], SunOS 5.x, probably later versions of SVR4 - and, if you include the Linux STREAMS stuff that I think exists, Linux), and you can have OSes with or without LKMs that don't support STREAMS.

LKMs are a mechanism for adding code to the kernel, and removing code from the kernel, at run time; STREAMS is a mechanism for gluing together modules that process sequential streams of data (e.g. serial ports, networks, etc.). STREAMS modules can be LKMs (some if not all are LKMs in Solaris).

The idea of STREAMS (and of Dennis Ritchie's original version (well, that paper is actually on additional stuff in Ninth Edition UNIX, but it briefly describes the original streams stuff in the Eighth Edition), which inspired the System V version is interesting; the implementations have, shall we say, had their problems (I have the impression that STREAMS buffer allocators can be slow - that may have caused some of the problems with the STREAMS based tty subsystem I did for SunOS 4.0 - and that getting STREAMS to work well on an MP system took rather a lot of work, and several Solaris releases, on Sun's part).

I use Solaris at work, and I can honestly say that it occasionally makes me want to look into W2K (then the head trauma wears off).

I primarily use Solaris at work, with some Digital UNIX and some Linux, and I can honestly say that

1. it's a UNIX, like the other OSes I mention, and like the FreeBSD that's the main OS I run at home;
2. it occasionally annoys me, but I could probably say that about just about every OS I use and have ever used - I think you pretty much have to pick the annoyances that annoy you the least (or, as I like to put it, "all software sucks - you just have to pick the software that sucks least in the areas you care about the most").

I don't think such things should be patented.

The DCT is an important thing, and shouldn't be ignored, but what about wavelet transforms? Wim Sweldens, the CREW people and others have looked at integer implementations. Wavelets discussed by the CREW people can be implemented with shifts and adds, as the DCT described above. I haven't heard of any patent problems with JPEG 2000, which will be based the wavelet transform, and will use integer transforms in some cases.

Assuming an omniscient God, then all any scientist is doing is rediscovering knowledge. A patent then is a bit pretentious.

1. The late, great Rich Stevens's children's college fund
2. Larry Wall's children's college fund
3. Dennis Ritchie's retirement fund.

• Most Improved Kernel Module: FreeBSD's Linux emulation module.

• Unsung Hero: In descending order:
  • Kirk McKusick, for his more than two decades of tireless service and personal sacrifices for our community.
  • Gurusamy Sarathy, Perl project release manager, responsible for bringing fork(2) to Microsoft ports of Perl and a million other things to make Perl code truly robust and portable between Microsoft and Unix platforms, a true Godsend for those of us forced to co-exist on both.
  • Malcolm Beattie, for trailblazing the Perl-to-C compiler, the Perl external byte-code interpreter, the first Perl/Tk implementation,threading in Perl, and safe blackbox compartments for mobile agents in Perl.

• Best Newbie Helper: Mike Stok from comp.lang.perl.misc. He is patient and kind, never chiding nor arrogant. He has been doing this job for many years.

• Most Deserving Open Source Charity: The Usenix Association. They don't take sides. They promote technology and open standards while remaining vendor neutral. They promote all aspects of advanced technology, but are especially supportive of open source solutions. No organization has done more to legitimize us over the last twenty-five years.

• Best Open Source Advocate: Larry Wall. He doesn't rant against anyone, tries to help everyone, and gives his code away for use by anyone, even Microsoft users. He doesn't restrict his good works to things that only benefit his friends. He doesn't preach, but lives by example.

• Best Unix Desktop Eyecandy: The newest version of the randomizing X screensaver. It's really great in a room full of people on acid.

• Best Unix Desktop Earcandy: The following entry in one's .Xdefaults file:

  *visualBell: on

• Best Desktop Theme: ShinyMetal

• Best Open Source-Related Book: In order of highest to lowest, all worthy of the award:
  • Writing Apache Modules with Perl and C by Lincoln Stein and Doug MacEachern.
  • Damian Conway's Object-Oriented Perl.
  • Elements of Programming With Perl by Andrew L. Johnson.

• Best Perl Module: Damian Conway's Class::Multimethods module for traditional OO in Perl.

• Best Apache Module: mod_perl; how can there be any question?

• Best Open Source Text Editor: The vim editor (vi improved), complete with its gvim graphical incarnation and its perl and python plug-ins.

• Best Deserving of a $2,000 Award:
  1. The late, great Rich Stevens's children's college fund
  2. Larry Wall's children's college fund
  3. Dennis Ritchie's retirement fund.
  (Perhaps those count as charities :-)

• Best Designed Interface in a Graphical Application:
  1. The eesh shell for controlling Enlightenment.
  2. The ddd debugger
  3. MacOS X's environment.

• Best Designed Interface in a Non-Graphical Application:
  1. The {Free,Open}BSD ports collection: being able to just cd and type make and have everything happen is the best thing that ever happened to third-parts apps.
  2. The make menuconfig directive for building Linux kernels.
  3. The v4.0 trn newsreader, with scoring and plug-ins.

• Best Dressed: Larry Wall, whether he's wearing Hawaiian shirts, tie-dies, or best of all, his outlandish, pastel-coloured tuxedos.

• Favorite Slashdot Comment Poster:
  1. Guy Harris
  2. Tom Christiansen
  3. Enoch Root
  4. Jay Maynard

• Favorite Slashdot Author: David Brin wins this one hands down.

• Best Slashdot Story of 1999: Eric Raymond's story about viruses on Microsoft vs Unix.

• Big Dumb Patent Bully: Amazon, followed by Unisys.

• Big Dumb Domain Bully: NSI, followed by Etoys.

• Clue Stick Award for FUD in Journalism: Slashdot.

Oi! Why wouldn't they use an unsigned for the time? Seems like Ken Thomson and Dennis Ritchie were planning on negitive times ;)

Or support for times prior to 1970, at least.

However, the answer may be "what's an 'unsigned'?" According to the version of the C Reference Manual that came with 6th Edition UNIX, there was no unsigned data type - that was added later. That manual is online, but only in Postscript, and is linked to from Dennis Ritchie's home page; here's the document itself.

Wait a sec (pun intended)
0111 1111 1111 1111 1111 1111 1111 1111
would incriment to
1000 0000 0000 0000 0000 0000 0000 0000
then
1000 0000 0000 0000 0000 0000 0000 0001
which are -0 and -1 respectively, right?

Right on machines using sign-magnitude representation, but not on machines using two's-complement representation, as most UNIX machines are (there existed, at least at one point, a UNIX port to the Univac 36-bit mainframes; those were, I think, one's complement).

In two's complement, on a 32-bit machine,

1000 0000 0000 0000 0000 0000 0000 0000

is -2147483648, and

1000 0000 0000 0000 0000 0000 0000 0001

is -2147483647.

Oi! Why wouldn't they use an unsigned for the time? Seems like Ken Thomson and Dennis Ritchie were planning on negitive times ;)

Or support for times prior to 1970, at least.

However, the answer may be "what's an 'unsigned'?" According to the version of the C Reference Manual that came with 6th Edition UNIX, there was no unsigned data type - that was added later. That manual is online, but only in Postscript, and is linked to from Dennis Ritchie's home page; here's the document itself.

Wait a sec (pun intended)
0111 1111 1111 1111 1111 1111 1111 1111
would incriment to
1000 0000 0000 0000 0000 0000 0000 0000
then
1000 0000 0000 0000 0000 0000 0000 0001
which are -0 and -1 respectively, right?

Right on machines using sign-magnitude representation, but not on machines using two's-complement representation, as most UNIX machines are (there existed, at least at one point, a UNIX port to the Univac 36-bit mainframes; those were, I think, one's complement).

In two's complement, on a 32-bit machine,

1000 0000 0000 0000 0000 0000 0000 0000

is -2147483648, and

1000 0000 0000 0000 0000 0000 0000 0001

is -2147483647.

Dennis Ritchie isn't much better. But if all ugly people ever invent something as useful as UNIX, they're really forgiven :) Eric Allman (Sendmail) isn't much better. Andreas Beck and Emmanuel Marty (GGI) are a little better if probably not unfamiliar with drugs ;-) Looks to me like we all have a quota that can't go to both programming skills and looks. I take the skills any day tho.

[RMS] wrote the original bc manual

3.Anyone have any idea how to fix the problem of dynamic IPs?

• Read Bill LeFebvre's article on Internet Black Holes to learn how the Real-Time Black Hole system uses DNS creatively. You can also go write to the source if you prefer. Here's an excerpt:

  The simplest way to get started using the MAPS RBL to protect your mail relay against theft of service by spammers is to arrange for it to make a DNS query (of a stylized name) whenever you receive an incoming mail message from a host whose spam status you do not know.

• Here's the abstract for TCP Splicing for Application Layer Proxy Performance, by Pravin Bhagwat et al.:

  Application layer proxies already play an important role in today's networks, serving as firewalls and HTTP caches -- and their role is being expanded to include encryption, compression, and mobility support services. Current application layer proxies suffer major performance penalties as they spend most of their time moving data back and forth between connections, context switching and crossing protection boundaries for each chunk of data they handle. We present a technique called TCP Splice that provides kernel support for data relaying operations which runs at near router speeds. In our lab testing, we find SOCKS firewalls using TCP Splice can sustain a data throughput twice that of normal firewalls, with an average packet forwarding latency 30 times less.

• Here's the abstract for Improving HTTP Caching Proxy Performance with TCP Tap:

  Application layer proxies are an extremely popular method for adding new services to existing network applications. They provide backwards compatibility, centralized administration, and the convenience of the application layer programming environment. Since proxies act as traffic concentrators, serving multiple clients at the same time, during peak load periods they often become performance bottlenecks. In this paper we present an extension of the TCP Splice technique called TCP Tap that promises to dramatically improve the performance of a HTTP caching proxy, just as TCP Splice doubled the throughput of an application layer firewall proxy.

• Cohen, A., S. Rangarajan, and H. Slye. On the Performance of TCP Splicing for URL-aware Redirection. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, pp. 117-125, October 1999.

  Recently, the focus of the work on NEPPI applications was mostly on high performance URL-aware switching using TCP splicing. TCP splicing is a technique for bridging TCP connections at the IP level within the kernel, thus avoiding the overhead of application-level copying between sockets as performed by programs such as proxies. URL-aware switching with TCP splicing can be utilized in layer 7 switches to achieve high performance content-aware redirection of HTTP requests. We have developed of prototype of a layer 4/7 switch based on NEPPI.

• A Mobile Networking System based on Internet Protocol(IP) Pravin Bhagwat, Charles Perkins. Proceedings of USENIX Symposium on Mobile and Location Independent Computing, August, 1993, Cambridge, MA.

  Due to advances in wireless communication technology there is a growing demand for providing continuous network access to the users of portable computers, regardless of their location. Existing network protocols cannot meet this requirement since they were designed with the assumption of a static network topology where hosts do not change their location over time. Based on IP's Loose Source Route option, we have developed a scheme for providing transparent network access to mobile hosts. Our scheme is easy to implement, requires no changes to the existing set of hosts and routers, and achieves optimal routing in most cases. An outline of the proposed scheme is presented and a reference implementation is described.

• A Mobile Host Protocol Supporting Route Optimization and Authentication IEEE Journal on Selected Areas in Communications, special issue on "Mobile and Wireless Computing Networks," 13(5):839-849, June 1995. c IEEE. Andrew Myles Department of Electronics

  Host mobility is becoming an important issue due to the recent proliferation of notebook and palmtop computers, the development of wireless network interfaces, and the growth in global internetworking. This paper describes the design and implementation of a mobile host protocol, called the Internet Mobile Host Protocol (IMHP), that is compatible with the TCP/IP protocol suite, and allows a mobile host to move around the Internet without changing its identity. In particular, IMHP provides host mobility over both the local and wide area, while remaining transparent to the user and to other hosts communicating with the mobile host. IMHP features route optimization and integrated authentication of all management packets. Route optimization allows a node to cache the location of a mobile host and to send future packets directly to that mobile host. By authenticating all management packets, IMHP guards against possible attacks on packet routing to mobile hosts, including the interception or ...

• RFC 2230 has some words that might be relevant here:

  Dial-Up Host Example

  This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.

  Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.

  Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic

  DNS Update without authentication is a significant security risk and hence is not recommended for this situation.

3.Anyone have any idea how to fix the problem of dynamic IPs?

• Read Bill LeFebvre's article on Internet Black Holes to learn how the Real-Time Black Hole system uses DNS creatively. You can also go write to the source if you prefer. Here's an excerpt:

  The simplest way to get started using the MAPS RBL to protect your mail relay against theft of service by spammers is to arrange for it to make a DNS query (of a stylized name) whenever you receive an incoming mail message from a host whose spam status you do not know.

• Here's the abstract for TCP Splicing for Application Layer Proxy Performance, by Pravin Bhagwat et al.:

  Application layer proxies already play an important role in today's networks, serving as firewalls and HTTP caches -- and their role is being expanded to include encryption, compression, and mobility support services. Current application layer proxies suffer major performance penalties as they spend most of their time moving data back and forth between connections, context switching and crossing protection boundaries for each chunk of data they handle. We present a technique called TCP Splice that provides kernel support for data relaying operations which runs at near router speeds. In our lab testing, we find SOCKS firewalls using TCP Splice can sustain a data throughput twice that of normal firewalls, with an average packet forwarding latency 30 times less.

• Here's the abstract for Improving HTTP Caching Proxy Performance with TCP Tap:

  Application layer proxies are an extremely popular method for adding new services to existing network applications. They provide backwards compatibility, centralized administration, and the convenience of the application layer programming environment. Since proxies act as traffic concentrators, serving multiple clients at the same time, during peak load periods they often become performance bottlenecks. In this paper we present an extension of the TCP Splice technique called TCP Tap that promises to dramatically improve the performance of a HTTP caching proxy, just as TCP Splice doubled the throughput of an application layer firewall proxy.

• Cohen, A., S. Rangarajan, and H. Slye. On the Performance of TCP Splicing for URL-aware Redirection. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, pp. 117-125, October 1999.

  Recently, the focus of the work on NEPPI applications was mostly on high performance URL-aware switching using TCP splicing. TCP splicing is a technique for bridging TCP connections at the IP level within the kernel, thus avoiding the overhead of application-level copying between sockets as performed by programs such as proxies. URL-aware switching with TCP splicing can be utilized in layer 7 switches to achieve high performance content-aware redirection of HTTP requests. We have developed of prototype of a layer 4/7 switch based on NEPPI.

• A Mobile Networking System based on Internet Protocol(IP) Pravin Bhagwat, Charles Perkins. Proceedings of USENIX Symposium on Mobile and Location Independent Computing, August, 1993, Cambridge, MA.

  Due to advances in wireless communication technology there is a growing demand for providing continuous network access to the users of portable computers, regardless of their location. Existing network protocols cannot meet this requirement since they were designed with the assumption of a static network topology where hosts do not change their location over time. Based on IP's Loose Source Route option, we have developed a scheme for providing transparent network access to mobile hosts. Our scheme is easy to implement, requires no changes to the existing set of hosts and routers, and achieves optimal routing in most cases. An outline of the proposed scheme is presented and a reference implementation is described.

• A Mobile Host Protocol Supporting Route Optimization and Authentication IEEE Journal on Selected Areas in Communications, special issue on "Mobile and Wireless Computing Networks," 13(5):839-849, June 1995. c IEEE. Andrew Myles Department of Electronics

  Host mobility is becoming an important issue due to the recent proliferation of notebook and palmtop computers, the development of wireless network interfaces, and the growth in global internetworking. This paper describes the design and implementation of a mobile host protocol, called the Internet Mobile Host Protocol (IMHP), that is compatible with the TCP/IP protocol suite, and allows a mobile host to move around the Internet without changing its identity. In particular, IMHP provides host mobility over both the local and wide area, while remaining transparent to the user and to other hosts communicating with the mobile host. IMHP features route optimization and integrated authentication of all management packets. Route optimization allows a node to cache the location of a mobile host and to send future packets directly to that mobile host. By authenticating all management packets, IMHP guards against possible attacks on packet routing to mobile hosts, including the interception or ...

• RFC 2230 has some words that might be relevant here:

  Dial-Up Host Example

  This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.

  Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.

  Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic

  DNS Update without authentication is a significant security risk and hence is not recommended for this situation.

You make a very, very good point. Isn't there a way the Linux and *BSD kernel could be patched to disallow execution from a stack? I know there's plenty of memory protection and such in there, so can't we put in one more layer of protection?

So, let's just change chips. :-) Of course, that's hardly enough. Can't we clear up a lot of these exploits by fixing the stack? The answer is yes, we could clear up a lot of them. But that sadly, it's not going to cure the class of problem completely.

Why should stack and data pages be executable? Why are any pages that are executable also writable? Well, there are a couple reasons for that. Certainly it hasn't always been that way. But the signal trampoline code from gcc(1) makes this very attractive, and it's a bit annoying to change. You still have to deal with issues of mmap(2), which can ask for pages with any access bits it cares for.

And let's not pretend please that C is the issue here. It's not. You're diddling the instruction set. I don't care if you used a Pascal compiler. You could still diddle it. Then again, there's something to be said for having a cleaner library. See the end of this missive for a simple, elegant, and effective approach to one class of these problems in C by someone famously inclined toward the simple and elegant.

What I strongly suggest that anyone interested in this do is read existing literature on this. Yes, it's work, but it's really, really good for you. Start with the paper StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. And yes, the buffer overrun in the version of Perl referenced by this paper has long since been fixed. But then read about how to defeat this. You can also check out disabling an executable stack on Solaris, and why this isn't a cure-all.

Even with a non-executable stack, you can still be bitten. Several such exploits have appeared on bugtrak. Here's one. The short explanation for why this isn't a panacea is that if I push a pointer to "/bin/sh" and a (char *)0 on the stack in a place right before an system(3) (well, or or execl(3) or execve(2) or whatever) then it'll still suck to be you. Notice I haven't executed any code that I put on the stack. I just managed to change some of the arguments to existing calls.

Let me put up a copy of some mail from Ted T'so, who said it well:

Well with a non-executable stack most security conscious system administrators will sleep better :) I can guarantee that. (Not too much better as holes always exist but quite a lot).

The advantage of the patch is that it will stop the current set of attacks that take the form of "find buffer overrun in a program", followed by "apply standard toolkit to exploit buffer overrun by putting executable code on the stack".

The disadvantage of the patch is that after we apply, within a few months we will see a new toolkit of the form "corrupt the stack to point the return address into someplace entertaining in libc --- like right before an an execl call in the implementation of popen()."

The danger is people thinking that with this patch, they don't need to worry about finding and fixing buffer overrun bugs in their code....

Here's the promised gem of insight from Dennis:

> ..... If most implementers will ship gets() anyway,
> there's little practical effect to eliminating it from the Standard.

On the other hand, we removed it from our library about a week after the Internet worm. Of course, some couldn't afford to do that.

Dennis

The Internet Mapping Project

Peacock Maps (buy one for xmas!)

-- jbum

BSD and Solaris are both offshoots of the original (v7?) Unix source, one side developed by Berkeley, the other side by AT&T, with a lot of cross-pollination. Linux was independently developed to be compatible, without the original source.

Read about the history of unix by one of the original dudes... (dmr).

FreeBSD, NetBSD, and OpenBSD should have no proprietary source left, they've been cleaned up so they could open the source. OpenBSD is a latecomer, basically a distribution/offshoot (of NetBSD?) designed for security, both by hopefully fixing security problems before they are exploited in the code and having a secure default configuration.

I've messed more with SunOS, Solaris, and Linux than I have with any of the *BSD's, tho...
---
pb Reply or e-mail rather than vaguely moderate.

BSD and Solaris are both offshoots of the original (v7?) Unix source, one side developed by Berkeley, the other side by AT&T, with a lot of cross-pollination. Linux was independently developed to be compatible, without the original source.

Read about the history of unix by one of the original dudes... (dmr).

FreeBSD, NetBSD, and OpenBSD should have no proprietary source left, they've been cleaned up so they could open the source. OpenBSD is a latecomer, basically a distribution/offshoot (of NetBSD?) designed for security, both by hopefully fixing security problems before they are exploited in the code and having a secure default configuration.

I've messed more with SunOS, Solaris, and Linux than I have with any of the *BSD's, tho...
---
pb Reply or e-mail rather than vaguely moderate.

Whether or not you buy the book, and whether or not you think of yourself as a programmer, if you consider yourself a thinking person, you should take this quiz. If you can't do back-of-the-envelope calculations, you should find this out as soon as possible, and fix the problem while you still can.

Whether or not you buy the book, and whether or not you think of yourself as a programmer, if you consider yourself a thinking person, you should take this quiz. If you can't do back-of-the-envelope calculations, you should find this out as soon as possible, and fix the problem while you still can.

UNIX (Linux) was hard to learn. There was little documentation. There were few users. It was only used by engineers.

1. UNIX (Linux) was hard to learn.

   Hard to learn compared with what? Compared with tying my shoe? Certainly. Compared with learning how to build a car? Hardly. Compared with learning what you have to learn to graduate from high school? Far, far from it. Hard compared to the vocational training needed in other jobs? The depends on the job. Sometimes yes, sometimes no.

2. There was little documentation.

   My goodness, whatever can you be talking about? Are you unaware of how revolution the Unix approach to documentation actually was? The BSD 4.4 documentation set, co-published by Usenix and O'Reilly, remains remarkably close to what we received in Version 7, although admittedly better than what we got in First Edition. I'm not talking about just manpages, either, essential though those are, but also the whole set of critical supplementary documents, all available on-line It's true that what some despectively refer to as "Winix" seems too often to have forgotten this lesson, but it was clearly present and revolutionary.

3. There were few users.

   Again, there seems to be a difference of perspective here. Sure, maybe in the early 70s there weren't many, but by the early 80s, there were countless thousands upon thousands upon thousands of users. I remember putting 3,000 students per semester onto Unix systems, just as my university. There were scores of others across the world doing the same thing, but with higher numbers.

4. It was only used by engineers.

   Not at all. It was used by huge numbers students, mathemeticians, programmers, scientists, and everybody else, even secretaries. At one point in time, the secretaries at very large institutions used vi to draft troff documents for all internal paperwork. They weren't idiots, but this is hardly rocket science.

UNIX (Linux) was hard to learn. There was little documentation. There were few users. It was only used by engineers.

1. UNIX (Linux) was hard to learn.

   Hard to learn compared with what? Compared with tying my shoe? Certainly. Compared with learning how to build a car? Hardly. Compared with learning what you have to learn to graduate from high school? Far, far from it. Hard compared to the vocational training needed in other jobs? The depends on the job. Sometimes yes, sometimes no.

2. There was little documentation.

   My goodness, whatever can you be talking about? Are you unaware of how revolution the Unix approach to documentation actually was? The BSD 4.4 documentation set, co-published by Usenix and O'Reilly, remains remarkably close to what we received in Version 7, although admittedly better than what we got in First Edition. I'm not talking about just manpages, either, essential though those are, but also the whole set of critical supplementary documents, all available on-line It's true that what some despectively refer to as "Winix" seems too often to have forgotten this lesson, but it was clearly present and revolutionary.

3. There were few users.

   Again, there seems to be a difference of perspective here. Sure, maybe in the early 70s there weren't many, but by the early 80s, there were countless thousands upon thousands upon thousands of users. I remember putting 3,000 students per semester onto Unix systems, just as my university. There were scores of others across the world doing the same thing, but with higher numbers.

4. It was only used by engineers.

   Not at all. It was used by huge numbers students, mathemeticians, programmers, scientists, and everybody else, even secretaries. At one point in time, the secretaries at very large institutions used vi to draft troff documents for all internal paperwork. They weren't idiots, but this is hardly rocket science.

A more informative link is here.

Read bell labs blurb on their web site here they do get a /bit/ more technical...not much though i'm afraid...

<bigwig> is a research project under BRICS. We are constructing a high-level programming language for developing interactive web services. Complete specifications are compiled into a conglomerate of lower-level technologies such as CGI, HTML, and JavaScript.

Our goal is to remove many of the obstacles that face current developers of web services to lower cost while increasing functionality and reliability. The <bigwig> language is an intellectual descendant of the MAWL project.

Among the issues we address are:

• persistent data
• sequential threads
• safe and dynamic construction of html documents
• concurrency control
• databases
• cryptologic security
• applet integration
• interaction with external services
• management of services
• monitoring of processes and data

You're full of it. The laser was a direct follow-on to the maser, and was developed at Bell Labs. See here.

Talk all you want about "some college kid"... it just ain't so...

PS - Charles Townes and the other inventors won the joint 1964 Nobel Prize in Physics for their invention.

Peacock Maps has a couple of posters based on the Internet Mapping Project data.

If you've got a good color printer, you could get the (fairly large) images here and print those. Of course, you'd then owe Unisys $10,000, since they're in gifs...

Lucent used to be Bell Labs (sort of). Bell Labs used to be part of AT&T (sort of).

Lucent used to be part of AT&T, and so did Bell-Labs. When Lucent split from AT&T, it took Bell-Labs with it, as its research division. AT&T's research division is now called AT&T labs.

bell-labs
AT&T labs

--ac

Don't believe me? Then why does Linux have a cccp command? The manual page says that it is a compiler preprocessor. That is what Linus and his fellow travellers would like you to think.

Take a look at the intro man page for plan 9. What computer do they use for editing, login and remote file access? kremvax!!!

Bill Gates makes sure that no commies can corrupt our children by enhancing Windows. Ask him for the source code, he will say "What are you, some sort of Communist?". Bill knows that "open source" is just a code word for the international Communist conspiracy.

And [Java] runs about as fast as Perl or Python, especially for non-graphical stuff.

One place where you can read more about this is in Timing Trials, or, the Trials of Timing: Experiments with Scripting and User-Interface Languages, a white paper by Brian Kernighan and Christopher Van Wyk.

Another interesting metric is taken from The Practice of Programming, by Brian Kernighan and Rob Pike (1999). It is difficult to reproduce the table here, because slashdot doesn't permit tables, preformatted tags, xmp tags, or even nonbreaking spaces. Sigh. (And no, this feature lack has nothing to do with Perl. They just chose for it to work this way.) I will try to uses hyphens instead of spaces, but no promises.

PLATFORM--------250mhz Irix-----400mhx pII MS---line count

C---------------0.36 sec--------0.30 sec--------150
Java------------4.9-------------9.2-------------10 5
C++/STL/deque---2.6------------11.2--------------7 0
C++/STL/list----1.7-------------1.5--------------7 0
Awk-------------2.2-------------2.1--------------2 0
Perl------------1.8-------------1.0--------------1 8

But this really should call into question the speed claims of the Java people. And it's my understanding that this benchmark did use the fabled JIT tech. It was a Markov chain generator, by the way.

And [Java] runs about as fast as Perl or Python, especially for non-graphical stuff.

One place where you can read more about this is in Timing Trials, or, the Trials of Timing: Experiments with Scripting and User-Interface Languages, a white paper by Brian Kernighan and Christopher Van Wyk.

Another interesting metric is taken from The Practice of Programming, by Brian Kernighan and Rob Pike (1999). It is difficult to reproduce the table here, because slashdot doesn't permit tables, preformatted tags, xmp tags, or even nonbreaking spaces. Sigh. (And no, this feature lack has nothing to do with Perl. They just chose for it to work this way.) I will try to uses hyphens instead of spaces, but no promises.

PLATFORM--------250mhz Irix-----400mhx pII MS---line count

C---------------0.36 sec--------0.30 sec--------150
Java------------4.9-------------9.2-------------10 5
C++/STL/deque---2.6------------11.2--------------7 0
C++/STL/list----1.7-------------1.5--------------7 0
Awk-------------2.2-------------2.1--------------2 0
Perl------------1.8-------------1.0--------------1 8

But this really should call into question the speed claims of the Java people. And it's my understanding that this benchmark did use the fabled JIT tech. It was a Markov chain generator, by the way.

http://www.bell-labs.com/news/199 9/june/24/1.html

For more info, of course...

If this column appeared on usenet, it would be called flamebait (or at least parts of it would). Perhaps that's a commentary on the state of conventional forms of journalism (eg. the columnist).

At any rate, most of what he said was silly and hyperbolic. Linux is 30-year old technology? Actually the oldest part of it is 8 years old, on average most of linux is 3 years old I'd estimate and its cycling all the time.

The writef obviously referred to when Ken Thompson first started working on a distinguishable OS later to be called Unix. Yes that was 1969, but what did Unix look like in 1969? It barely had worked out the concept of directories and devices. (Check out Ritchie's article on describing what using Unix was like in the first few years here.) Does that look anything like Linux or Unix today?

Unix (and Linux) will be around in 30 years (albeit in an evolved form) simply because it can run on anything! Think about all the trends in computing that Unix has outlived because it adapted. Linux is the most dynamic and adaptable Unix ever invented because it is so open.

Are we going to be using intel-based PCs with keyboards and SVGA monitors in 30 years? Something's wrong if we are. Will Windows be able to adapt? Nothing Microsoft has done in recent years has demonstrated any degree of innovation or adaptability. Will the open source community just eventually dump the linux code base? Why would it?

In 30 years, Unix will be here. Windows won't.

1 Gigabit/s, bah humbug! What I want is 10 Gigabit/s like the folks at Lucent/Bell Labs are playing around with. No sh*t folks, 10!

They'll be showing this off this week. You can get the info about a LAN and a multiplexer.

This sort of makes our workplace upgrade to a 100Base-T switch look sort of feeble.:)

1 Gigabit/s, bah humbug! What I want is 10 Gigabit/s like the folks at Lucent/Bell Labs are playing around with. No sh*t folks, 10!

They'll be showing this off this week. You can get the info about a LAN and a multiplexer.

This sort of makes our workplace upgrade to a 100Base-T switch look sort of feeble.:)