Slashdot Mirror

If you just want an extremely basic program to make 2-dimenstion bar, line, or scatter graphs, xgraph is about as bare-bones simple as they come.
It runs on any Unix and dumps PostScript output files. Sometimes anything more is overkill.

Cycorp is making progress, though.

I recommend reading Witbrock, Michael, D. Baxter, J. Curtis, et al. An Interactive Dialogue System for Knowledge Acquisition in Cyc. In Proceedings of the Eighteenth International Joint Conference on Artificial Intelligence, Acapulco, Mexico, 2003.

Also, if you are a lucky college student, go see the author talk about Cyc teaching itself at USC or Carnegie Mellon..

Oh, and for once, I actually am an expert on the topic, not that that matters on slashdot.

(Asserting the phone or mail systems aren't relevant does not make it so. I'd be interested in proof)

" Here's a newsflash for you, these networks are private and really, no matter what your opinion may be, they aren't open to anyone to use and/or abuse"

Hey, Vint Cerf says "The interent is for everyone ; this is published at IANA in RFC3271. It doesn't seem to say "except spammers".

(again, lest there be any confusion, I wish all spammers were beamed into a black hole)

If you turned on a mailserver to accept incoming connections from the Internet at large and were then surprised you got a lot of mail you don't want then you have a fundamental misunderstanding of how the Internet works these days.

If you only want to get mail from certain people then you can configure your mail daemon to so just that.

(Asserting the phone or mail systems aren't relevant does not make it so. I'd be interested in proof)

" Here's a newsflash for you, these networks are private and really, no matter what your opinion may be, they aren't open to anyone to use and/or abuse"

Hey, Vint Cerf says "The interent is for everyone ; this is published at IANA in RFC3271. It doesn't seem to say "except spammers".

(again, lest there be any confusion, I wish all spammers were beamed into a black hole)

If you turned on a mailserver to accept incoming connections from the Internet at large and were then surprised you got a lot of mail you don't want then you have a fundamental misunderstanding of how the Internet works these days.

If you only want to get mail from certain people then you can configure your mail daemon to so just that.

(Asserting the phone or mail systems aren't relevant does not make it so. I'd be interested in proof)

" Here's a newsflash for you, these networks are private and really, no matter what your opinion may be, they aren't open to anyone to use and/or abuse"

Hey, Vint Cerf says "The interent is for everyone ; this is published at IANA in RFC3271. It doesn't seem to say "except spammers".

(again, lest there be any confusion, I wish all spammers were beamed into a black hole)

If you turned on a mailserver to accept incoming connections from the Internet at large and were then surprised you got a lot of mail you don't want then you have a fundamental misunderstanding of how the Internet works these days.

If you only want to get mail from certain people then you can configure your mail daemon to so just that.

The article didn't say where the code was available. Does anybody know? All I could find was this:
http://www.isi.edu/licensed-sw/rewrite-decoder/ind ex.html
It might be the software to which the article refers, but the Knight fellows name isn't on it.

Jon's homepage

Also check RFC 2468.

J

The revolutionary part of TCP/IP was the idea of the catenet (concatenated networks). This allowed IP to run on top of all of the proprietary networks that existed

Check out this project. This is a sort of language/culture simulator intended to teach both languages and customs to soliders being deployed overseas. The whole thing is based on the Unreal game engine. There's a lot of potential for using video game tech as instructional technology.

There's a lot been done on multicasting stuff without the actual existence of IP Multicast (as is the case in much of the public Internet). It's funny this came up, seeing as my project at uni this year will turn out an implementation of an overlay multicast protocol on which I'll be able to run conferencing tools.

In the absence of my wonderful software, I'd suggest taking a quick look at Yoid, which should theoretically use your bandwidth intelligently. The applications which run on yoid without modification are few in number, but I believe they ship a modified version of VAT (Visual Audio tool). If not, and VAT runs on Yoid without modification, VAT can be found here: www-mice.cs.ucl.ac.uk/multimedia/software/ (the URL appears to be down just now. I'd imagine it should be back up soon-ish.)

Available on that site is some form of collaborative whiteboard system, which could (possibly) be useful for such an event.

Then try one of the other thousands of internets that President Bush talked about.

There was a fascinating article about some Caltech (?) researchers putting a little speech recognition into what was probably a Half-Life mod, and coming up with a 3rd-person shooter in which you had to learn Arabic words and phrases to complete missions. I think they were being funded by the DoD.

A point you made in a different reply was pretty interesting - that pronunciation calcifies after about a year. I'm curious - to what degree is that dependent on the intensity of study? I.e., would a person taking five classes a week reach that point faster than a person taking one or two classes at night?

"Standard" PCI has 1056Mbps of bandwith. According to the site he mentioned, they are using a machine that has a 64 bit bus at 66MHz, which yields 4224Mbps of bandwidth. So you'll need to spend at least $200 for a motherboard that can hold your $16k capture card. :^)

Not true. DVS sell capture cards for uncompressed HDTV, which work with standard PCI slots and give you the raw video signal (at just over 1 gigabit per second). Not cheap - we paid $16k for ours, although they've gone down since then - but definitely possible.

We use it for uncompressed HDTV video conferencing on Linux... The capture card isn't the expensive part :-(

There is no need to replace the procol to fix either problem. ECN was deisgned to fix the former problem and AFIK there has been plenty of research put into fixing the the backoff mechanism.

Hmmm. On this picture there are several cars that have seriously run into each other, and at least one that swerved off the side of the road...

What's the spread on Miami this weekend?

Since the two languages have striking similarities, one wonders when people will begin to develop source code translators to shield problem-oriented developers from the idiosyncrac differences between the two languages.

For instance, ISI's STELLA is a LISP dialect which compiles to Common LISP, C++ and Java(R). Along the same line, it would be nice to have a compiler for a "JaC#" language that compiles to both, utilising tons of Java APIs and C#'s ability to do native compilation (I am aware there are portability limits, but I'd much rather be able to be confined to a common subset while able to easily move between the C++/Java/C# worlds than using obscure language features that others can't decipher anyway).

--
Try Nuggets , our mobile answer search engine. We answer your questions via SMS, across the UK.

You are completely wrong.

Draft Standard is a Standards Track Maturity Level. RFC is a document type.

You were probably thinking of Internet-Drafts, which are not the same thing as RFCs. RFCs must first be published as Internet Drafts. Internet-Drafts are removed after 6 months if they are not approved by the IESG for publication. RFCs are archived.

The zeroconf documents are Internet-Drafts. They are not RFCs.

As with RoboCup, I expect the gap between the first and third years to be huge. And to think our little QuickCam/Linux RC cars won robocup #1.

Anm

Most sensor network research groups are developing their own protocols since TCP/IP and other standard protocols are perceived to be too heavy-weight, and usually do not match the specialized application conditions in the wireless network. For instance, a wireless sensor in most cases do not need a unique identity such as an IP address - it is the sensor data that is important, not the individual sensor devices. There is a very commonly used protocol called "Directed Diffusion" (link) that is used to gather sensor data from a wireless network. This protocol runs directly on top of the physical link layer, without any protocol layers beneath it.

That said, there are people working on bringing the TCP/IP protocols to wireless sensor networks (a project at SICS in Sweden) but it hasn't reached wide-spread usage yet.

Let me give some straight facts through all this futuristic market speak in the articles and from my professor. Where are we now?

1. We are trying to do a proof-of-concept that a team of robots can indeed assemble structures together in a near-frictionless environment.

2. We are currently trying to build a triangle out of 3 reconfigurable beams assembled by a pair of tethered robots. With a triangle we can realize more rigid and useful structures such as trusses.

3. We are halfway there. We have achieved two-beam assembly with reconfigurable connectors and everything.

We have been working on this thing for almost a year, and one of the things you might be asking is why is this so difficult?

1. Main issue is connectors. You want to have connectors that can be automatically assembled together yet provided tight tolerances and carry heavy loads. These are often conflicting requirements and this has required a lot of tinkering to accomplish.

2. Reconfigurable connectors. These are connectors that not only automatically connect, but also automatically disconnect. Give the above requirements in 1 and this becomes doubly more difficult.

3. Precision control in a "near-frictionless" yet noisy environment. This is very difficult. Our positioning is kind of crude, our propulsion is non-linear, and the noise in the air-table is not predictable. We've been able to accomplish a lot of our results by using the tether to pull the two robots together and assemble the beams together with a rolling motion.

For those of you who are interested in seeing our latest results I recommend going to the media page at our lab here

The last video (which is surprisingly not up yet) is here

For future reference, the research involved in "evolving and adapting" has not yet been done. That is future work.

Thanks,
Jacob Everist
everist@usc.edu

Let me give some straight facts through all this futuristic market speak in the articles and from my professor. Where are we now?

1. We are trying to do a proof-of-concept that a team of robots can indeed assemble structures together in a near-frictionless environment.

2. We are currently trying to build a triangle out of 3 reconfigurable beams assembled by a pair of tethered robots. With a triangle we can realize more rigid and useful structures such as trusses.

3. We are halfway there. We have achieved two-beam assembly with reconfigurable connectors and everything.

We have been working on this thing for almost a year, and one of the things you might be asking is why is this so difficult?

1. Main issue is connectors. You want to have connectors that can be automatically assembled together yet provided tight tolerances and carry heavy loads. These are often conflicting requirements and this has required a lot of tinkering to accomplish.

2. Reconfigurable connectors. These are connectors that not only automatically connect, but also automatically disconnect. Give the above requirements in 1 and this becomes doubly more difficult.

3. Precision control in a "near-frictionless" yet noisy environment. This is very difficult. Our positioning is kind of crude, our propulsion is non-linear, and the noise in the air-table is not predictable. We've been able to accomplish a lot of our results by using the tether to pull the two robots together and assemble the beams together with a rolling motion.

For those of you who are interested in seeing our latest results I recommend going to the media page at our lab here

The last video (which is surprisingly not up yet) is here

For future reference, the research involved in "evolving and adapting" has not yet been done. That is future work.

Thanks,
Jacob Everist
everist@usc.edu

Or you could just arrange to send a Cache-Control: no-cache header. Seriously dude, just read RFC 2616 (HTTP/1.1) and do a search for "no-cache". No need to redirect and waste an HTTP request. And if you don't want the overhead of CGI, just use mod_asis on Apache to send precisely the headers you want.

Which should be in just a few years, apparently. Google gives: Summarization at Univ. Southern California/ISI Summarization at Columbia University Narrative in Italy Narrative at Carnegie Mellon

1. Why functional programming matters by John Hughes. An oldie but goodie, this can get you motivated to actually learn the language.
2. Hal Daume's Haskell tutorial is very complete, free and much better than the "Gentle Haskell Introduction" which isn't very gentle at all.
3. The Haskell Language definition is the official language description.
4. GHC's library reference, which you will use constantly on anything non-trivial.
5. The foreign language interface manual. Since Haskell has a small library you will probably need to call functions written in C a lot to get anything done. Luckily, Haskell's foreign function interface is quite nice.

Internet Standard #1 (currently RFC-3600 - November 2003) lists TCP as being Standard #7, which is outlined in RFC-793. RFC-793 was published in September 1981. In other words, we are still using the 1981 edition of TCP. RFC-793 contains the following note from Jon Postel:

This document is based on six earlier editions of the ARPA Internet Protocol
Specification, and the present text draws heavily from them.

Thus, Dr. Rhee is a little bit off in his assesment.

While the interview is light on details, there is more information available online.

Don't forget how the system works. Darpa basically hands out money for research into areas it finds interesting. Coincidently, I've been involved for a short time in a research project dealing with exchanging present day IP (mostly the heavyweight gorilla listening to the name TCP) with smaller, more adaptable alternatives.

Two projects in this field that I've heard of
are

the knowledge plane and
application private networks

The basic idea, AFAIK, is to do away with the one size fits all model of networking and replace it with a more adaptive lego-like stack. For this to work you need information on the state of the network in order to build your optimal dynamic stack. A possible source for this might be the discussed knowledge plane. Also, actual micro-protocols need to be created and some sort of decision making system must be in place (APnets). Shameless plug of my own work
here.

I don't know of other projects, but if Darpa has opened its wallet for this cause you can expect many other universities to have similar initiatives underway.

There have been a number of recent advances in concept-to-speech synthesis, which incorporates a sort of map (I'm being very general here) of the semantic concepts in a text and uses that to determine where emphasis should go to make speech sound more natural.

I think there's a lot of promise in fusing this approach with the discourse-representation work of people like Daniel Marcu -- automatically extract the discourse representation, then use that to assign prosody.

Sorry if this is a bit technical -- I do something very similar to it for a living, so it's easy to geek over.

Been there, done that. Only runs at 1Gbps though, because the host struggles when doing simultaneous video capture and transmission at those rates... :)

See lavaps
for an example applying this concept to track processes (CPU consumption and memory usage) on a Unix system.

Of course, 8 years ago when Mark Weiser did this, he called it "calm" technology.

That's a pretty glaring error, if we're talking about the same IPv6 spec.

I think you are saying that "QoS" is necessary to VoIP, because if VoIP is flakey, the end users won't use it.

I then think you are really saying that VoIP is a latency sensitive application, so the network has to be engineered to meet the latency requirements of VoIP.

The issue then is how you meet those latency requirements ?

There are a couple of ways you can do that :

• Ensure that there is enough capacity in the network such that it very rarely gets congested to the point where VoIPs latency requirements cannot be met.
• Provision less capacity in the network, and then use various managed QoS mechanisms, such as CBQ, etc, to manage the congestion in the network when it occurs. Congestion in this network will occur much more often than the network with the additional capacity.

So which solution do you choose ?

As a rule, simplicity usually wins out. Maybe not in the first instance, but eventually, over time, things tend towards simplicity. Simplicity tends to be cheaper, and everybody aims for cheaper. There is always a demand in the market for cheaper, and commonly, the only way to achive cheaper is to go simpler.

Costs of running a network are broken into two areas - Capital Expenses (ie. usually initial, setup costs), and Operational Expenses (ie. ongoing running costs).

Comparing the above solutions, the one thing the second has that the first doesn't have is a lot of active bandwidth management and measuring. This can be very expensive to do, when you consider the number of devices and links within the network. It can also be very complicated, as it increases the number of protocols running in the network, and the number of people who need to be paid to watch and operate the network. The QoS solution is not the simpler of the two solutions. The second solution has higher operational expenses than the first.

Comparing the two solutions using capital expenses, I'd suggest the initial set costs of the first solution would only be in the order of about 20% more than the second, accounted for by the additional bandwidth expenses incurred.

The question to ask then is "how long will the 20% cheaper start up cost of the second solution be absorbed by the higher operational expenses of the second solution ?"

My answer is "not all that long". Which indicates that the "throw bandwidth at it" solution, in the longer term, is both simpler and therefore will be cheaper.

As further evidence, consider the Internet. There is very little QoS management on the Internet, with the exception of a recommendation of a default queuing alorithm - Random Early Detection. The Internet solution is to "throw bandwidth at it". Yet most of the time Internet provides good enough "QoS" to allow people to make voice and video calls across it. Certainly good enough to sustain voice calls that are equivalent or better than mobile or cell voice calls eg GSM. Based on that evidence, you don't need to implement QoS technology inside the network to sustain the latency required for typical VoIP applications.

In the Internet, simplicity has won.

Be careful which RFC, and which TCP, you mean: RFC 675, "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM," or RFC 760, "DOD STANDARD INTERNET PROTOCOL." The original TCP was the precursor to IP, and Cerf and Kahn invented it. The RFC for IP edited by Postel (a later RFC replaced it) was a refinement of Cerf and Kahn's work.

You web browser probably contains a cache of this page, did you (or it) ask permission beforehand? It could even be argued that the absence of a 'Cache-control: no-cache' header, which the content originator could quite easily add if they don't wish their content to be cached, is an implicit permission to mirror the content.

This tool seems like a stripped down version of NS2. With NS2 you can roll your own protocol and implement it using their reasonably powerfull scripting language (oTcl .. pronounce Oh - tickle) or create your own C++ code to do the job. They have every wired protocol I can think of implemented, 95 percent of wireless ones (including some satellite) and it also comes with NAM; a GUI to show you the nodes and flow and such. Runs on *nix and windows with cygwin

I actually develop and work with voice synthesizers that are phoneme and phrase based. We dig up an actor, or an unwitting researcher from another project, and make them rattle off a few thousand sample sentences. Then, in theory, we use that date to make a "realistic" human voice. Yeah. Sure. Riiiiiight. If it worked, I'd be out of a job. :) Technology has come a very long way, but it is no where near what a real person can do. It can't even imitate. The spoken word is a thousand times easier than singing, I'll believe it when I hear it sing what I say within an hour of placing a request. By the way, I proposed that we develop a rapping version of our synthesized voice, just for fun. The idea was trashed in 30 seconds, b/c who wants a voice that raps like an off duty LAPD Sergeant at Karaoke night? I doubt this thing can sing that well...

My research lab is working on a project to do just this. We're developing a system to assemble structures in space using an array of distributed self-reconfigurable robots. You can view the project at this website: SOLAR

http://www.isi.edu/deter/

More info can be found here on the USC Information Sciences Institute website

oops i forgot to linkify that url.

Whatever happened to IPv5? What was special about it?

Google is your friend.

What would be considered as IPv5 existed only as an experimental non-IP real time streaming protocol called ST2 described in RFC 1819. This protocol was abandoned in favor for RSVP.

http://www.rfc-editor.org/howtopub.html
ftp://ftp.isi.edu/in-notes/rfc2026.txt (The Internet Standards Process -- Revision 3)

This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.

The IANA of course delegate the right to distribute IP address blocks to the RIRs(RFC 2050), who in turn do so to the ISPs. Thus any other search engine can prepare a spider-generated (or otherwise) list of results. For Google to remove a few links from their results does not in anyway change the reality that the IP addresses continue to exist and therefore potentially contravene the DMCA(not that I agree with this in the first place). the IANA, RIRs and ISPs therefore potentially contravene the DMCA - why then would Google take the step of removing links from their results? I'm sure Google has some kind of disclaimer relating to URLs people visit from their results - you can visit more gross sites than kazaalite!

Full Disclosure: I deployed some CRM software for Google in 2000

(Sorry folks, but this was just asking for it, dontcha think? :-D )

Electricity as a LAN? You mean thisRFC?

With all the loopholes in the current SMTP specification,is it possible for the Slashdot collective to come up with another one?

To start with, I would suggest a detailed look at RFC 2549.

The Standard for the Transmission of IP Datagrams on Avian Carriers described therein is fairly broad and could prove a feasible alternative to current email delivery mechanisms, specifically SMTP.

The reason I think it hasn't taken off since 1999 is that it proposes to completely replace IPv4 (like IPv6). Maybe it would be easier to first phaseout SMTP over IPv4 for now, rather than the whole IP layer.

That's an example from a few years' back of an attempt to translate "the spirit is willing but the flesh is weak" from English to Russian and back to English using a different translator.

Can anyone try this on the new (or some other recent) algorithm?

BTW here's Doc Och's most recent website:

Franz Josef Och [isi.edu]

--
Esteem isn't a zero sum game

That's an example from a few years' back of an attempt to translate "the spirit is willing but the flesh is weak" from English to Russian and back to English using a different translator.

Can anyone try this on the new (or some other recent) algorithm?

BTW here's Doc Och's most recent website:

Franz Josef Och