cmu.edu · Domains · Slashdot Mirror

Links to good info by Otto · 2000-05-30 03:46 · Score: 1 · on Pushing Microwaves Faster Than Light

Quick Google search yields:
http://www.andrew.cmu. edu/user/dcprieve/Evanescent%20waves.htm
to describe what they are.. Doesn't say much about the second part of your question though.

---

Re:Local calls, packet queuing, linmodems by carton · 2000-05-28 08:51 · Score: 2 · on Free Software Voice Over IP Solutions?

It would be a lot easier to respond to your posting if you had included some hyperlinks. I am interested in your pet theories, but I don't have time to go searching for each one by hand.

The problem with fair queueing on modems is that the internal buffer inside the modem is usually quite large (on the order of 10 packets), and this buffer isn't subject to queueing. AFAIK the buffer must stay inside the modem for reasons of Tradition and V.42b. All real-time/fair queueing algorithms must muck with the output queue. For real network cards rather than modems, this means NIC drivers can reorder packets inside the FIFO onboard the network card. Each hardware NIC driver must have fair queueing support to deliver a good implementation. Therefore, it will never happen with traditional modems. You will have to buy a new modem, which may not exist yet.

I think you are talking about fair queueing w.r.t. ``Linux-diffserv'' because diffserv is the name of an IETF fair queueing working-group.

There is a lot of research on fair queueing. It deals with issues like the one you discuss, voice packets pre-empting large FTP packets. However, all the papers I've read are a much more advanced discussion than knee-jerk reactions like introducing another complexity into the protocol stack. They typically start with a GPS model in which each packet is 1 bit long, and then generalize the results for discrete packets. The ordering of the packets is actually a lot more interesting than their size.

This research was basically completed about five years ago with Hui Zhang's HFSC algorithm, which is implemented in the ALTQ package for *BSD. ALTQ is part of the KAME IPv6 stack that the three BSD's are importing into their trees and tracking as it evolves.

The relevant aspect of these algorithms is their ability to allocate bandwidth and latency separately and predictably. A high-bandwidth, high-latency FTP connection can share the same packet-switched link with a low-bandwith, low-latency VoIP connection. This is what ``real-time scheduling'' means. Although usually those words refer to CPU scheduling, the ideas and algorithms involved are similar if not identical.

This software is a real Computer Science answer to the age-old phone company allegations that only circuit-switched networks will ever reliably carry bounded-latency multimedia streams. It is not new, although it may be new to Linux or to popular use. If implemented on the whole Internet, it's basically proven that these algorithms can guarantee a clean, low-delay connection with no dropouts.

There are other papers about how to distribute some of the processing so these algorithms can scale to the core backbone, as well as stuff about extending them to wireless networks. Some of this research may be ongoing.

Anyone know which VoIP stacks work with IETF's diffserv ideas or RSVP?

Rational Programming is Not an Oxymoron by Baldrson · 2000-05-27 21:57 · Score: 2 · on What Will The Internet Of The Future Be Like?

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

Re:You might consider Alice by waldoj · 2000-05-26 04:25 · Score: 1 · on Best Way to Get Kids Started in Programming?

I alpha-tested Alice at UVa in...oh...'98, I guess. Maybe '97. Hell of a lot of fun, and a great media lab. I didn't get to program in it, but it was a fantastic user experience.

-Waldo

Alice! by smallpaul · 2000-05-26 02:42 · Score: 1 · on Best Way to Get Kids Started in Programming?

Things that are visual tend to get kids' attention. Check out

Alice:

Alice is a rapid prototyping system for virtual reality software. Alice programs are written in an object-oriented, interpreted language which allows programmers to immediately see the effects of changes. As an Alice program executes, the author can update the current state either by interactively evaluating program code fragments, or by manipulating GUI tools. Although the system is extremely flexible at runtime, we are able to maintain high interactive frame rates (typically, 20-50 fps) by transparently decoupling simulation and rendering. We have been using Alice internally at Virginia for over two years, and we are currently porting a "desktop" version of Alice to Windows 95. We will distribute desktop Alice freely to all universities via the World Wide Web;

Testimonial

What is so remarkable about Alice is the degree to which it brings 3D graphics programming down from on high and puts it in the hands of non-computer scientists. With very little assistance, my 7 year-old son created programs in hours that would have taken me, a professional 3D graphics programmer, days to write using OpenGL.

Paul Prescod

My Goals by ch-chuck · 2000-05-23 03:00 · Score: 2 · on What are Your Programming Goals?

My goal is to write a universal 'bullshit detector' that can apply the derivation rules of logic from 'Principia Mathematica' to first principles of metaphysics and the grand unification theorm, creating all basic sciences, nuclear-plasma physics, astrophysics, chemistry, biology, medicine and then finally the psychology of human sexual behavior. This ambitious project, on hold awaiting govt funding, entails a self maintaining massive database of 'truths' derived (under human direction as to 'revelancy' to human needs, sort of a trusted derivable encyclopedia) from said fundamental principles, with the cognative ability to catagorize any random statement into TRUE or FALSE in a reasonable amount of time by cross correlating it to the massive database as logically derivable from self evident axioms or not, complete with referances to prior research, bibliography and derivation path (for human checking of logic) - sort of like an automated library research assistant, or like a web search engine but only capable of producing 'true' information, while all unfounded, non-derivable speculative ideas and plain ol' B.S. are weeded out as 'false' or at lease 'not yet proven', particularly the system's self-referential 'Gödel' theorms.

I'd like to implement this with a massive cluster of superconducting R TX-2001's or better yet the PSC1000 using a FORTH microcode as the propositional logic processor but haven't decided on the high level language yet. Even that physical implementation probably needs updating.

Re:the kernel ain't bsd by TheGS · 2000-05-22 22:26 · Score: 1 · on Aqua DP4 Review And Screenshots

You're right.

There's the pure Mach microkernel itself, an integrated kernel, and a full (but outdated!) Mach-based OS distribution derived from BSD.

This URL provides more information about the different forms of Mach that are available:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/ public/FAQ/distribution.info

What we do for 50,000 Users.. by jdigital · 2000-05-21 19:26 · Score: 1 · on From POP3 To IMAP-What Solutions Are There?

Recently I was heavily involved in changing over from a Sendmail based system to a new mail system that had to be designed to cope with 50,000 users in an ISP setting.

To keep things short, I'll tell you where we ended up :

Postfix replacing sendmail for SMTP stuff. We decided to go this way for reasons of fairly straightforward compatability with sendmail in terms of alias and virtual user tables, but with an overall simpler configuration scheme. Postfix also appeared to be much more efficient in terms of CPU and Memory usage. One big plus was the off-the-shelf support for LDAP for users, maildrops and aliases. We are moving alot of our systems across to LDAP and one less application for me to add LDAP support to made things easier. At the office we run this on FreeBSD 3.4, and at home I have run it on BSD, Linux and Solaris with no problems.
Cyrus IMAP/POP server from Carnegie Mellon. Previously we were running Cubic Circle's cucipop program which proved to be a great package, but the code is so nutty that any attempts to hack it resulted in great frustration. Cyrus also offered LDAP support, but some hacking was required to get things to fit in with our schema, and to get the authentication just right. It took about 10 minutes to insert the code for DRAC (POP before SMTP authentication). Running on FreeBSD.
Smunge - a service side package I wrote to let users check 2 POP boxes as if they were one. This also has LDAP and DRAC support out-of-the-box (tm) :) - Builds on Linux, Solaris and FreeBSD.
Hoarde IMP we used as a web email client (talking via imap, whereas dial up customers could only use pop)- Running on Solaris.
For Radius we currently use FreeSide, but we are moving towards Merit. I have written an LDAP authentication module for Merit, and I'm waiting for the OK from my bosses to GPL it. BSD and Solaris.
LDAP - we like LDAP :) We currently run OpenLDAP on a production server. We have tinkered with Netscapes Directory Server, but you can only configure that through some crappy slow java interface, and that kinda sucks.

As for the question of IMAP vs. POP, I think you really need to look at the practicalities of offering one over the other. I won't go over it all again (I know somone else has posted on the same line) but IMAP is not really the way to go for an ISP/dial-in/remote-user environment. I think it perhaps it was even on www.imap.org that I found a quote stating that IMAP was best utilised in a University environment.

I know I'm not really answering your question, but I thought you might be interested to see a path someone has taken.

Re:the kernel ain't bsd by bugg · 2000-05-20 02:22 · Score: 1 · on Aqua DP4 Review And Screenshots

Sure, you're correct.

But MACH _is_ a BSD. Mach was based on 4.2BSD, and by the time Mach 2.5 rolled around it was enhanced by code from 4.3BSD.

In fact, the improvements from CMU/MACH eventually made its way into 4.4BSD... most notably the VM subsystem.

Want proof? Besides any BSD/UNIX family tree, or the 4.4BSD book, there's always the following URL:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/ public/www/FAQ.html
Despite all of the mentions of 4.3BSD, if you're too lazy to follow the URL or just want a summary, this line covers all bases:
Before you can get a Mach license, you must have a Fourth Berkeley Software Distribution (4.3BSD) license.

Please don't try to correct someone when you don't know what you are talking about!

Finally... a story where this is *not* offtopic... by Anonymous Coward · 2000-05-19 20:38 · Score: 5 · on Oxford Yanks Student Page Over Spoof DeCSS

and I'm asleep at the keyboard. Doh!

Oh well... here it is.
Add your own, and spread this far and wide:

This announcement brought to you by the DeCSS Polar Bear.

Re:Seems almost like ISO... by Coz · 2000-05-19 09:59 · Score: 1 · on Space Shuttle Software: Not For Hacks

That's the point of SEI Level 5 - "Continuous Process Improvement."

I've worked on programs assessed at Levels 3 and 4, and supposedly the folks I work with now are Level 5 (I know they made 4, but I'm not sure the certification for 5 is finished). I grind my teeth sometimes at the layers of process we have to wade through to get things done - but every six months or so, they make changes to (hopefully) make it better.

The SEI's not just working with software - they're developing models for System Engineering and Integrated Product Development, as well as Personal and Team software process models for small and independent-minded folk. Your tax dollars at work!

Re:Seems almost like ISO... by Coz · 2000-05-19 09:59 · Score: 1 · on Space Shuttle Software: Not For Hacks

That's the point of SEI Level 5 - "Continuous Process Improvement."

I've worked on programs assessed at Levels 3 and 4, and supposedly the folks I work with now are Level 5 (I know they made 4, but I'm not sure the certification for 5 is finished). I grind my teeth sometimes at the layers of process we have to wade through to get things done - but every six months or so, they make changes to (hopefully) make it better.

The SEI's not just working with software - they're developing models for System Engineering and Integrated Product Development, as well as Personal and Team software process models for small and independent-minded folk. Your tax dollars at work!

Their code is good because... by Anonymous Coward · 2000-05-18 23:07 · Score: 2 · on Space Shuttle Software: Not For Hacks

their process ensures it will be. The vast majority of software development is performed in an environment where individual "heroes" are the primary reason projects succeed. The Space Shuttle Onboard Software processes will seem to almost all of us to be "common sense", but how many of us work in a place where management mandates these things to ensure quality? Their environment is "ideal" because they have made it so. Unfortunately, many managers' (and too many developers', also) attitudes can be described as "get it done", and it shows!

They were rated CMM level 5 in 1988 - one of the first organizations anywhere rated at that level of software process maturity. Another good description of their processes (and how they created them) is in the book "The Capability Maturity Model - Guidelines for Improving the Software Process" (ISBN 0-201-54664-7) in Chapter 6, "A High-Maturity Example: Space Shuttle Onboard Software".

As far as making software error-free, a quote from the book will help illustrate the difference in attitude they have (it's talking about a graph). "These data include failures occurring during NASA's testing, during use on flight simulators, during flight, or during any use by other contractors. Any behavior of the software that deviates from the requirements in any way, however benign, constitutes a failure. Contrast this level of commitment with the cavalier attitude toward users in most warranties offered by vendors of personal computer software."

The best place to find more about the CMM is their web site at http://www.sei.cmu.edu/

Re:Flight Software by jammz · 2000-05-18 20:29 · Score: 2 · on Space Shuttle Software: Not For Hacks

I thought they were the only group to achieve SEI-Level 5. If not, then who else has, I'd love to go and correct one my lecturers.

When the Capability Maturity Model for Software was published by the SEI there was only one ML-5 orginzation; at the time they were known as the IBM Onboard Shuttle group. Thankfully, times are changing.

According to the SEI's 1999 survey, 61 organizations reported a Maturity Level of 4 or 5. Of those, 40 were Level 4 groups and 21 were Level 5. The survey goes on to mention that as of 15-Feb-2000, some 71 organizations reported that they were Level 4 or 5. Those that gave their consent are listed in Apendix A.