Slashdot Mirror

Prolog seems more popular outside .us, but that seems to be a territorial thing to me (Lisp was invented in .us, while the major dialect of Prolog is called "Edinburgh Prolog"). Japan, especially, had a big thing for Prolog in the 80s, but it seems to have died off (along with, thankfully, Turbo Prolog).

I actually tend to prefer Prolog for AI-type things, and use Common Lisp as my general-purpose language. It's also worth noting that implementations of simple Prologs in Lisp abound.

--

Here is a list of online books and references which I found useful:

• Common Lisp: A Gentle Introduction to Symbolic Computation -- David S. Touretzky
• Successful Lisp: How to Understand and Use Common Lisp -- David B. Lamkins
• CLtL2: Common Lisp the Language, 2nd Edition -- Guy L. Steele
• HyperSpec: The ANSI Standard for Common Lisp -- Kent M. Pitman
• CLOS: Common Lisp Object System -- Daniel G. Bobrow et al
• MOP: The Meta Object Protocol
• CLIM2: Common Lisp Interface Manager 2.0
  The CLIM perspective, user's guide, and specification.

Here is a list of online books and references which I found useful:

• Common Lisp: A Gentle Introduction to Symbolic Computation -- David S. Touretzky
• Successful Lisp: How to Understand and Use Common Lisp -- David B. Lamkins
• CLtL2: Common Lisp the Language, 2nd Edition -- Guy L. Steele
• HyperSpec: The ANSI Standard for Common Lisp -- Kent M. Pitman
• CLOS: Common Lisp Object System -- Daniel G. Bobrow et al
• MOP: The Meta Object Protocol
• CLIM2: Common Lisp Interface Manager 2.0
  The CLIM perspective, user's guide, and specification.

Here is a list of online books and references which I found useful:

• Common Lisp: A Gentle Introduction to Symbolic Computation -- David S. Touretzky
• Successful Lisp: How to Understand and Use Common Lisp -- David B. Lamkins
• CLtL2: Common Lisp the Language, 2nd Edition -- Guy L. Steele
• HyperSpec: The ANSI Standard for Common Lisp -- Kent M. Pitman
• CLOS: Common Lisp Object System -- Daniel G. Bobrow et al
• MOP: The Meta Object Protocol
• CLIM2: Common Lisp Interface Manager 2.0
  The CLIM perspective, user's guide, and specification.

Try looking around at the Software Engineering Institute site. They study such issues, and have standards of sorts. They're more oriented towards process than product, though.

The BOWGO (patent pending) is a new kind of pogo stick that bounces higher, farther and more efficiently than conventional devices. The BOWGO is a product of the Toy Robots Initiative and is a scaled-up, human-sized version of the Bow Leg. The Bow Leg is a highly resilient leg being developed for running robots at Carnegie Mellon University's Robotics Institute. The key technology is the fiber-reinforced composite (FRC) spring that bends like a bow to store elastic energy. Compared to the steel coil spring used in a conventional pogo stick, the bow spring stores 2-5 times as much energy per unit mass, and precludes the sliding friction that results when long coil springs buckle sideways. The BOWGO also uses rollers to guide the plunger, in place of the usual plastic guide bushings, providing smooth, almost frictionless motion. The force/deflection characteristic of the bow spring is tailored to provide high-energy storage with minimal shock at ground contact. A large, rubber-padded foot allows the BOWGO to be used on relatively soft surfaces such as grass, sand and gravel. (We recommend using the BOWGO only on soft surfaces and away from any obstacles that might cause injury.)

Two prototypes, BOWGOI and BOWGOII, have been built and tested with a number of users and spring designs. Performance has greatly surpassed our expectations. A third prototype is presently in the works that should push performance even higher. We are currently seeking licensees for the technology.

The BOWGO (patent pending) is a new kind of pogo stick that bounces higher, farther and more efficiently than conventional devices. The BOWGO is a product of the Toy Robots Initiative and is a scaled-up, human-sized version of the Bow Leg. The Bow Leg is a highly resilient leg being developed for running robots at Carnegie Mellon University's Robotics Institute. The key technology is the fiber-reinforced composite (FRC) spring that bends like a bow to store elastic energy. Compared to the steel coil spring used in a conventional pogo stick, the bow spring stores 2-5 times as much energy per unit mass, and precludes the sliding friction that results when long coil springs buckle sideways. The BOWGO also uses rollers to guide the plunger, in place of the usual plastic guide bushings, providing smooth, almost frictionless motion. The force/deflection characteristic of the bow spring is tailored to provide high-energy storage with minimal shock at ground contact. A large, rubber-padded foot allows the BOWGO to be used on relatively soft surfaces such as grass, sand and gravel. (We recommend using the BOWGO only on soft surfaces and away from any obstacles that might cause injury.)

Two prototypes, BOWGOI and BOWGOII, have been built and tested with a number of users and spring designs. Performance has greatly surpassed our expectations. A third prototype is presently in the works that should push performance even higher. We are currently seeking licensees for the technology.

The BOWGO (patent pending) is a new kind of pogo stick that bounces higher, farther and more efficiently than conventional devices. The BOWGO is a product of the Toy Robots Initiative and is a scaled-up, human-sized version of the Bow Leg. The Bow Leg is a highly resilient leg being developed for running robots at Carnegie Mellon University's Robotics Institute. The key technology is the fiber-reinforced composite (FRC) spring that bends like a bow to store elastic energy. Compared to the steel coil spring used in a conventional pogo stick, the bow spring stores 2-5 times as much energy per unit mass, and precludes the sliding friction that results when long coil springs buckle sideways. The BOWGO also uses rollers to guide the plunger, in place of the usual plastic guide bushings, providing smooth, almost frictionless motion. The force/deflection characteristic of the bow spring is tailored to provide high-energy storage with minimal shock at ground contact. A large, rubber-padded foot allows the BOWGO to be used on relatively soft surfaces such as grass, sand and gravel. (We recommend using the BOWGO only on soft surfaces and away from any obstacles that might cause injury.)

Two prototypes, BOWGOI and BOWGOII, have been built and tested with a number of users and spring designs. Performance has greatly surpassed our expectations. A third prototype is presently in the works that should push performance even higher. We are currently seeking licensees for the technology.

And how does the paper represent a "circumvention device"? DeCSS fits that definition, for sure - download the software, and you can rip DVD's. (Disclaimer: I'm not at all agreeing that that should be illegal - I'm just saying that DeCSS is a real circumvention device.)

I beg to differ from your statement that DeCSS is a circumvention device. Just like CSS is the specification for an encryption method, DeCSS is also, in my humble opinion, just a specification. It is a specification which, I agree, can be used to implement a device that can play encrypted DVDs, but it is not, in itself, a circumvention device. DeCSS is just something that tells one how to do something, and in my opinion is protected by Free Speech. The specification can be in any form, speech included, but does not do ANYTHING until you actually implement it.

P.S.:
But just watch. The next thing you know is that they will lobby to rid us of even our freedom of speech. We cannot afford to just sit and let that happen.

Those guys over in the Data Storage Systems Center ain't got nothin' on the one true CMU MEMS Lab. Oh, sure, they've got genuine applications that people actually need and that can show a profit and stuff, but we've got weird far-reaching projects like microstructured scaffolds for growing engineered tissues! (Don't bother looking; it's not linked from the page 'cause the website never gets updated.)Why, we've got genuine doctors (with MDs and everything!) working with us to build new biosensors! *And* we've got a display case!

Anyway, I'm sure we'll be turning out profitable projects any day now. No, really. Just wait.

• Inefficient kernel-user switching (i.e. system calls spend too much unecessary time in the kernel).
  
  
• Inefficient address switching (i.e. the number of cache and TLB misses in the Mach microkernel is also absurdly large).
  
  
• The performance of IPC operations and thread switching is subpar. (this is related to the above points).
  
  
• It isn't optimized for specific hardware and instead has a Hardware Abstraction Layer which slows it down considerably.

While we're dropping cool terms in the story header, let's pretend for a moment that no one knows what MEMS based storage is, and give them the link to the MEMS Research Unit at CMU, where they are prototyping and developing this stuff right now.

The short story is that it's a very small sled containing magnetic data (on a substrate) that is pushed by very small actuators of an assembly over read/write heads. It fits on the price/speed/storage curve somewhere in between hard drives and Flash. If you want to know more from people who actually know what they're talking about, read the intro and then click on their research papers.

I sure wish you could buy the stuff, but it's still a few years from primetime.

Over time I've found this to be ridiculously true, and am deeply saddened by the lack of, well, not mainstream acceptance of Lisp, because mainstream acceptance always destroys anything good, but a willingness to let me, as a professional, select a language which:

• allows me to be incredibly productive
• is one of the few languages that really allow me to feel one with my code
• is not slow, nor necessarily (or usually) interpreted
• is not limited to AI
• does, in fact, allow iteration
• has many advanced data constructs beyond lists
• has the best general-purpose OO system I've ever seen
• is fun to hack in Emacs :-)

Sigh. Anyone have any Lisp jobs for an enthusiast and advocate with about a year's informal experience and a love of the language?

--

Over time I've found this to be ridiculously true, and am deeply saddened by the lack of, well, not mainstream acceptance of Lisp, because mainstream acceptance always destroys anything good, but a willingness to let me, as a professional, select a language which:

• allows me to be incredibly productive
• is one of the few languages that really allow me to feel one with my code
• is not slow, nor necessarily (or usually) interpreted
• is not limited to AI
• does, in fact, allow iteration
• has many advanced data constructs beyond lists
• has the best general-purpose OO system I've ever seen
• is fun to hack in Emacs :-)

Sigh. Anyone have any Lisp jobs for an enthusiast and advocate with about a year's informal experience and a love of the language?

--

While I'm reading a book on Java ("Java 2": The Complete Reference, by Osbourne publishers) the author frequently makes comments on how Java differes from C++ in case a C++ programmer is reading. Every difference is an improvement.

No, they claim every difference is an improvement. That's a good book -- I own it -- but their advocacy often crosses the line of sanity.

Like when they defend the whole single inheritance fiasco. They use the example of a House and how you'd want to make it inherit Foundation, Walls, and Roof. Makes sense, right? But then they say to make Walls extend Foundation, and Roof extend Walls, and House extend Roof. Um, a roof isn't a wall. It shouldn't have wall-specific methods.

Java does have some things going for it. It's a neat little platform for applets and set-top boxes. But it is vastly overused in settings for which it is painfully unsuited (like Web servers). And certain pathetic hacks to get around the confinements of Java (such as using "interfaces" to pretend for a second that Java can almost simulate multiple inheritance, but wretchedly) just cause more spaghetti code, pain, and suffering.

Try a real object system sometime. You'll like it.

--

Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?

Get over it!

I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang? Haskell? Scheme? Prolog? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.

You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.

Nor really... The AI in games is minimal at best when compared to the capabilities of AI in a theoretical sense. The problem is that AI is difficult to design and takes alot of time, and developers are out to make money, so they invest in technologies that will immerse the player in the game to get them addicted to it.

Its a new type of addiction for me, because I'm not playing to see how far I get, or see how big my avatar will get, its to see what he does next when he's off my leash. Was he watching when I was throwing the rocks, and start throwing villagers? Was he watching me pickup and move villagers to do the same?

So, it may be a long time before some really sophisticated AI gets into games, if ever. Think about it, if a chess computer can beat the world champion, don't you think there are strategies in many of these games that would be similarly difficult to beat?

If you want cutting-edge AI, don't look at games, look at OSCAR at the U of Arizona, or at the MIT Media Lab , or at the stuff going on at CMU or RPI. That's where the real progress and research is being done. Not in some programming sweatshop at EA.

I am going to begin speaking as if you have read the "How does AVES work" page. If you haven't, do it now. When I say "locks up", I mean the waypoint won't be able to create new connections to a different NATed machine.

Essentially the problem is that there is a very easy DOS attack, that cannot be removed by the design of the system.

Basically, what you do is you make a bunch of DNS requests without ever making a connection. This will allocate all of the waypoints. If my understanding of this system is correct, a DNS lookup will allocate the waypoint to the specific machine for quite at least a few seconds (so that the proxy can form) if not longer (otherwise it may have problems with applications that cache the IP address, like IE, which don't do a DNS lookup for each connection).

So, find a bunch of unique DNSs (if you use the same DNS, the system can just reuse the same locked machine) that use the same service, and begin allocating. Pretty soon, no one will be able to make a connection to any subscriber.

Note that it is the whole machine that locks up waiting to form the bridge, because the DNS server can't know what port the remote application is going to try to use.

This goes back to the reason why I wouldn't use this system for web servers: there are other ways of having multiple machines as web servers behind a NAT that give you more control over the load.

I would limit this to home use, and even then, expect some script kiddies to knock out your service now and then.

In the paper, the researchers mention that that can cause problems with ingress filtering by ISPs, which can be fixed by forwarding the return traffic through the waypoint as well.

Read one of their papers.

There's exhaustion right here, right where Eugene is doing his research: CMU. We're running out of addresses, and look at this. Last semester they were handing out tshirts to those who agreed to use a dynamically assigned ip instead of a static, for both DSL and wireless users.

So really, I appreciate Eugene's research, especially if next year I'll be connecting through another ISP, that only gives me one static IP.

Maan

which will bollix up many kinds of firewalls.

The fourth diagram on the "How Does Aves Work?" page shows this clearly.

An example: my home firewall sees an HTTP request go out to pc.john.avesnet.net, for which (according to the explanation) a DNS lookup gets an IP address [1.2.3.4]. [1.2.3.4] is actually the IP of an "AVES waypoint" host. The waypoint processes my original HTTP request, and sends it along to the actual machine behind some NATbox (which has an IP of [5.6.7.8]) somewhere, which replies to my browser. But the reply doesn't originate from [1.2.3.4], which is where my firewall is looking for a reply to the original query -- instead, it arrives with a source IP of [5.6.7.8], which is the IP of the NATbox behind which pc.john.avesnet.net actually sits. To my firewall, this looks like an incoming connection attempt that is unrelated to any outgoing traffic, so it gets DROPped on the floor.

So, far from requiring no upgrades on the part of the end-browser, this scheme will require anyone with a firewall or a NATbox (such as my P90 running ipchains, or a linksys BEFSR41, or some other cablemodem/DSL access sharing device) to understand the protocol and deploy mechanisms for handling it.

The trouble with fine-grained security is that it requires fine-grained administration. This is the big problem with access control lists. Capabilities are a mechanism, not a policy. Once you have capabilities, you have to figure out how and when to issue them. That's hard. You tend to end up with a big, complex ticket-issuer.

A valid security policy needs transitivity. That is, if A can't do X, then A must not be able to induce B into doing X. Only mandatory security models enforce such properties. This is why they work, but they're a pain. Without this property, untrusted software can be exploited by attacks.

EROS is a reasonably clever idea, but it's not going anywhere. (KeyCos, its predecessor, was a good idea, too, but nobody could understand Norm Hardy.) EROS has persistent objects instead of files, which was probably a mistake. (In terms of persistence, what we seem to need today is very efficient support of non-persistent objects, like CGI programs. that do quick transactions and exit. Most of those programs should be executing with very limited privileges.)

The problem with a mandatory security model is that everything else, like package managers, web servers, browsers, etc. has to be reworked to live within it. (It's mandatory, so you can't go around it.) We need to find out if the current generation of widely-used open-source tools can be made to live within a strong mandatory security model. If they can, the security problem becomes far easier; we only have to fix little trusted apps, not big untrusted ones.

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.

Ok--now go read about the deaths of 80 innocent civilians in their own homes at the hands of US Defense and the FBI in 1993; read how the United States is the world leader in incarceration, with many of the jailed being casualties of the War on Drugs; read about the victims of racial profiling in the US ("Driving while black"); read about prison labour in the United States; or police brutality; perhaps even the many violations of international law by the United States.

Go read all of those links (and while you're at it, brush up on your history; for instance, slavery in the United States), and come back and tell me that you welcome the US as a power any more than China. Take off your rose-coloured US-media-manipulated glasses, and realize that America is as affected by propaganda convincing its citizens that their country faultless as China is.

From their site: Purdue, Sourceforge, CMU, Sunsite.dk. Purdue and dk's fast, CMU dead - YKMV.
--
mrBlond

CMM

The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design) is that the most popular implementation of the concept (Mach) is also one of the most inefficient and badly designed.

In Joseph Liedtke's 1995 paper, On Microkernel Construction he points out that the myth of Microkernels being more inefficient and thus slower than monolithic kernels is because most benchmarks were done against the Mach microkernel. He stated that the Mach performed poorly at both address switching and context switching and also failed to take processors into account and be optimized thusly. As a test, Liedtke wrote a Microkernel OS called L3 in which he showed that a call to getpid which took 800 cycles of kernel time on the Mach to be performed took 15 - 100 cycles on the L3.

Also he also disproved the notion that using a microkernel leads to memory degradation due to a large number of cache misses a dissects a number of benchmarks from Chen and Bershad's paper The Impact of Operating System Structure on Memory System Performance.

Read his paper if you get the chance, it's very enlightening.

The ideas behind microkernel design are very sound and some of them have found their way into most mainstream OSes (Linux kernel modules can be seen as a take on the Microkernel architecture). Basically, having an OS where everything is hot swappable including memory management, process scheduling and device drivers is kind of cool. Also the fact that the usual OS level APIs can now be swapped out meaning you can have both POSIX layer and a Win32 layer on the same OS is rather nice.

...the best professors that is. There is nothing more valuable than a good teacher. Frank Pfenning , in my opinion, is one of those great teachers. I am not a student of the university that he teaches at, but I can still follow along his courses, read his class notes and do his homework. I highly recommend his courses to any computer scientist who is interested in the foundations of computer science (constructive logic and the lot).

After following through Prof Pfenning's material, I have given allot of thought to going to CMU... I just need more money ;-)
Anyways, thanks CMU and thanks Prof Pfenning!

Barry K. Downey
U.S. Counsel to e-gold Ltd.

Looks like you left out your full title there "Vice President of huffing and Puffing".

So you are running a site out of an obscure caribean island offering financial services whose principal attaction appears to be being beyond the reach of US regulatory powers.

If I were in such a situation my first plan of action would not be to initiate libel lawsuits in the US which not only makes libel lawsuits almost impossible for plaintifs, but also empowers litigants with sweeping powers of discovery.

Everyone knows that if you want to piss Declan off you simply go to Pittsberg and buy officers Haven and Hammond-Schrock a drink.

I've seen a cool little toy/tool from the folks at Carnegie Mellon. It's called Alice, and it's a pretty interesting 3d graphics package for the web. Oddly enough I learned about this from a multimedia class. I'm a little more taken with Teddy2 and major props to Takeo Igarashi at the University of Tokyo. Teddy2 is a spiffy little tool for building objects. And as long as I'm plugging 3d graphics tools I like to putter around with, check out Texture Weapons. It is certainly worth checking out some of the demos. This isn't just another way to make 3d widgits...ok well maybe it is, but they are really cool widgits, and sometimes more.

After you've read the Maggs article check out the fascinating interview he has with Brian Kernighan... http://www.cs.cmu.edu/~mihaib/kernighan-interview/ index.html (It was actually posted on /. Sep 2000)

Hey, I was in 251 with him last year. Jason from the post above was in that class too. (Ha Ha, try to guess who I am) He's a pretty good professor, occasionally a bit boring but much better than many I've had, and he knows what he's talking about. Here's his homepage. Mod me up to 4 too, please.

Hey, I was in 251 with him last year. Jason from the post above was in that class too. (Ha Ha, try to guess who I am) He's a pretty good professor, occasionally a bit boring but much better than many I've had, and he knows what he's talking about. Here's his homepage. Mod me up to 4 too, please.

And all the CS students at CMU doing their Graphics projects start wondering:

What the hell happened to the CS server..? I can't get anywhere! Bleh, might as well read Slashdot...

Oh, *that's* what happened to the CS server...

As it says in the interview, Bruce Maggs is a professor at Carnegie Mellon. I was in a discrete math course that he taught about three years ago, and one of my classmates produced this comic-book-style look at what "Maggs-neto" does with his spare time (namely, plot world domination with the aid of a mind-controlled pack of Spice Girls). Bruce was a good sport about the whole thing -- images and references to the comic's story began appearing in his lecture notes & slides! Sadly, it was never finished...

It's so weird to load Slashdot, look at the top article, and think, "Hey, that's my professor for 213."

Take that, MIT!

The Internet is at once the greatest threat to and the greatest hope for our liberties. The threats: the web is increasingly the turf of a handful of media companies: Time Warner /AOL, for example. The web also contains sites which most people would find repellant, making it easier for the well-meaning and the prudes to demand access restrictions.

At the same time, the web is our greatest protection from tyranny. Look at what has happened with attempts to ban DeCSS code or obfuscate the power companies' complicity in the California crunch.

How did I run across these things in the first place? Simply by reading /. with a low threshhold. The truth is out there, but adults shouldn't expect to be spoon-fed.

Gaaah... You say:

It seems he has not looked into the whole DCMA thing though but tries to give generalities about it's use and incorporation. Let's keep on him for positive ability to decompile for fair use.

He says:

The most troublesome provision of the digital millennium copyright act is found in section 1201 (a ) (1) which makes it unlawful for a manufacturer to produce a device which is "primarily designed" for the purpose of infringing a copyright. ...

He's quoting sections at you. It looks like he's devoted some time to the DMCA, or at least looked it up in response to the question.

Rupert's post above is right. The guy seems a little more informed than Y.A.Policitian, and if someone got him clued on the whole DeCSS thing, he would take issue with the ruling. Having an amicus curae from a congress-man couldn't hurt either...

Jim Tomayko has taught an undergraduate course as an elective in the CS curriculum at Carnegie Mellon University (which I didn't take, but I've heard good things about). My quick web search for more info about the course came up empty, but you might be able to contact him directly for advice.

My colleagues routinely solve hard max-clique instances involving several hundred vertices on PCs. See, for example, the now 8-year-old 2nd DIMACS Challenge for more details including performance on specific instances.

... slashdot must remove this AC post. The E-meter is based on this NAS paper.

there's a link to a demon page in the document and it's broken already. i suggest that they link to the decss gallery.

i was angry:1 with:2 my:4 friend - i told:3 4 wrath:5, 4 5 did end.

Yeah, maybe. Research is currently being done on how to do this without the idea of a trusted party. The general idea is that the code comes with a proof of its safety (or a proof that it meets some other specification), which is "easily" verified by a small piece of software on your computer. It's not a panacea (there is a world of difficulty in specifying the right policies), but it could certainly stop updates of application-level (or especially applet-level) software from containing naughtiness.

Check out http://www.cs.cmu.edu/~petel/papers/pcc/pcc.html for more info on Proof Carrying Code.

It has nothing to do with the brand of network adapter, but rather a network protocol, BOOTP. BOOTP allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. See RFC 951 (1985) and the Diskless Nodes HOW-TO if you want to know how to implement this under Linux.

Sounds like another good reason to be a constructivisit. In Constructive mathematics, numbers are defined in terms of a total function which computes them (or, for a "real" number, a function which can get you arbitrarily close to them). None of this "let n = 1 if the continuum hypothesis is true, 0 otherwise" stuff! Constructive mathematics is pretty nice, though some "obvious" stuff is not provable.

Here's some links:

http://plato.stanford.edu/entries/mathematics-cons tructive/

http://www.cs.cmu.edu/~fp/courses/logic/

Of course, some classicists find delight in how insanely undecidable their mathematics is, and that's fine, too. =)

\Omega_{UTM} is a pretty cool idea, though, much worse than the standard trick of defining which has decimal digit n = 1 if turing machine n halts, 0 otherwise (also undecidable, but not as hopeless as his!). I wish I hadn't missed the lecture.

Quit bitching, and have a look at this: http://www.phatboydesigns.net/efdtt2.html (this is merely a cleaned up and syntax-highlighted version of the original efdtt.c, which can be found here, by Charles Hannum. This was mentioned in Slashback on March 15.)

Inspired by Phil's effort, a prime number encoding of the source of efdtt.c has been contributed by Charles M. Hannum.

Inspired by Phil's effort, a prime number encoding of the source of efdtt.c has been contributed by Charles M. Hannum.

Using the much shorter efdtt.c, there's another illegal prime number.

Using the much shorter efdtt.c, there's another illegal prime number.