Slashdot Mirror

Contiki was created by Adam Dunkels at SICS in 2003 and was quickly slashdotted. Its impact has been growing ever since.

Plus ça change, plus c'est la même chose.

Contiki has ipv6 support http://www.sics.se/contiki/current-events/uipv6-contiki-is-ipv6-ready.html

We are talking about software here not religion.

But there is FreeDOS which is probably what a good number of these DOS like embedded systems are running. Frankly that is why I didn't say MS-DOS. A lot of people use FreeDOS for this kind of work now. Some use DR-DOS and still others used MS-DOS. Frankly I would use FreeDOS myself unless there is some good reason not to but that is just me.
Please at this point you are just being silly. Linux is overkill for something like a CNC controller or radiation counter.
Plus for many of these applications it just will not work. Educate yourself just a little and you might actually stop wasting peoples time.
BTW if you need something that has a bit more capability than DOS does but still lighter than Linux there are options.
RTEMS will work for realtime systems but it is a lot more complex to set up than DOS but it runs on more CPUs and is general more flexible.
Another option is Contiki http://www.sics.se/contiki/about-contiki.html
But again the thing about DOS is simply so many people know everything there is to know about it. It is super well documented and the Development tools are everywhere and well known.
If you don't like DJCPP or the free Borland toolset you still have a ton of options left open including http://www.freepascal.org/
Linux is a great embedded tool when you need it. The thing is for a lot of tasks it is overkill and frankly just will not do the job as reliably and as cheaply as good old DOS will.
So go read up and and stop treating FOSS as a religion and start using it as a tool. And stop being a tool.

It would be a head of monumental proportions, but Contiki ( http://www.sics.se/contiki/ ) could probably be made to run on it. It would give you a gui interface of sorts and ipv6 support, though I doubt you could use that part.

You could try contiki.

http://www.sics.se/contiki/

Multitasking (No for both?)

http://www.sics.se/contiki/

Actually, if you RTFA, he didn't develop the TCP/IP interface.

This project uses an "MMC replay" C64 expansion box with an RR-net ethernet daughterboard installed. He wrote the Twitter client to run on the Contiki OS, which comes with a built-in TCP/IP stack and a driver for the RR-card. Credit for Contiki and it's uIP TCP/IP stack go primarily to Adam Dunkels:

http://www.sics.se/~adam/

The accomplishment of the C64 Twitter client's author is really more about writing a Twitter client with one hand tied behind your back rather than really being C64 specific. He wrote it in C (CC65 6502 compiler) on Contiki, so the fact that it happens to be running on a C64 as opposed to any other environment that supports Contiki is somewhat irrelevant.

Whether it scores any points for complexity really depends on your level of experience. Given that the ./ readership has become less and less hard core over the years, I think there are many people here who should be avoiding this guy's front lawn. At least, if you've never written any networking code in your life, how about firing up Linux, or installing MinGW (maybe roughly comparable to installing Contiki and CC65 on a C64), then writing your own Twitter client... It certainly won't be a waste of time if you learn how to do socket programming as a result.

DIVE seems to have done all this as early as 1993.

Hmm... Seems like DIVE "http://sics.se/dive" did all this as early as the early to mid 90s.

Have you thought about a functional language , so that you could just add X computers with Y cores and Z memory? I'm still learning Erlang, but to a point I can write neat servers that auto scale and balance.

Once you run the interpreter on each machine (one could use Damn Small Linux as your backbone) and set the network key: on erlang, it is
erlang:set_cookie(node(), password).

And it will push your code between so that things just work. As for the interpreted argument, look at Yaws, the Erlang web server. This convinced me.

Ok, now back to the original argument :
which, exactly, of these qualifies as an implementation, free-as-in-beer to download and build whatever out of it you may want to ?

Which, exactly am I supposed to install on my OpenMoko ?

Say I want to build the humorously often cited "internet-enable fridge". I want people to be able to ordrer their groceries from the fidge's interface. But the online grocery store runs on flash (bad idea), which flash should I install on my MIPS based system ?

Currently flash is in the same state as Skype. Yes, there are a couple of implementation that you can download. Yes, there are even a couple more specially built-for binaries used in a couple of embed device. But it's not a "feel free to slap it on whatever piece of hardware you can dream of" situation.

Whereas the "other" web standard, the one which is actually a real documented and multiple time implemented standard - HTML&HTTP, etc...
Is really free to be used wherever you want.
There are OS solutions for 8bits 6502 CPU that can browse HTTP pages.
For Zeus' sake there are even people managing to cram a web server inside a PIC.
That's a versatile technology you can put on anything you can think of.

Meanwhile, with Adobe you're just limited to the couple of platform that they conceded to support.
No way to be creative.

For an idea of scale just look how many device can run a Linux kernel, or Perl scripting engine.

This is like the 100th PIC-based web server. Do these guys never think to see if someone else has already done a PIC web server before writing their own? Hard to be sure since I can find mention of the dimensions, but this one looks to be about the same size. This one's been around for ages. And there plenty more. There's even this mini web server/tcp-ip stack for the PIC that compiles to a remarkable 30 bytes of PIC code.

Nothing to see here. Move along...

"We describe two small and portable TCP/IP implementations fulfilling the subset of RFC1122 requirements needed for full host-to-host interoperability. Our TCP/IP implementations do not sacrifice any of TCP's mechanisms such as urgent data or congestion control. They support IP fragment reassembly and the number of multiple simultaneous connections is limited only by the available RAM. Despite being small and simple, our implementations do not require their peers to have complex, full-size stacks, but can communicate with peers running a similarly light-weight stack. The code size is on the order of 10 kilobytes and RAM usage can be configured to be as low as a few hundred bytes."

So this is a compliant stack in 10k code. Quite a feat, if you ask me.

No, but lunix and contiki both do, and are both somewhat unix-like.

Hell, here is a guy browsing the internet on an Apple II When what you want is text, pretty much anything will suffice. http://www.sics.se/contiki/perspective/browsing-the-web-from-an-apple-ii-with-contiki.html

To me, the funniest part of that video is that they pointed a camcorder at the screen, when they could have just directly captured the Apple II's NTSC video output.

It was good enough for us back in the day, we programmed, word processed and communicated with TVs as monitors all with some proficiency and only minor... alright perhaps moderate eyestrain.

The colors, fonts, and interfaces were designed with ultra-low res displays in mind. While say, 12pt times new roman and arial are not.

http://upload.wikimedia.org/wikipedia/commons/4/49/AppleII.jpg Just look at this, that is a what, 6 inch screen? Barely larger than the 5 1/2 inch floppies next to it, in a picture taken from 4 feet away, compressed in a jpeg, and you can still make out all the letters.

Hell, here is a guy browsing the internet on an Apple II When what you want is text, pretty much anything will suffice. http://www.sics.se/contiki/perspective/browsing-the-web-from-an-apple-ii-with-contiki.html It's not ideal but CRT monitor/tvs were made better back then, they had finer controls and were just sharper, I used some old commodore monitors for years for video projects, probably the sharpest non-hd TV you can get that doesn't run you in the thousands, that and they are very stackable so you can have a tower of monitors.

Check out this.

still takes over 30 minutes to get a consistent speed greater than 100kbps on a so-called High Speed network!

Slow down there, champ. The BitTorrent protocol uses an approximate tit-for-tat strategy -- more peers will upload to you if you upload to more peers. This can take a while, which is why BT speeds generally trend up slowly, although I'll admit 30 minutes is a bit much even in my experience (I used to have comcast, now have at&t -- they're both crap, in short). It's all explained in this very clear and easy to read paper by Bram Cohen (the original protocol author) : Incentives Build Robustness in BitTorrent (PDF link).

Thanks to Contiki OS you can have a complete operating system with a web browser on a good ol' C64, Atari 800... Now that's unbloated software!

I am (well, was, at least) an Erlang Programmer. I was toying around with Erlang for some small projects with distributed programming.

I've been looking forward to Joe's book for a long time, as he's one of the few big names in the Erlang community, and has done a lot of work (both code and, even more importantly, documentation) for the community -- first that jumps to mind is his important look at Yaws vs. apache.

There are serious problems with the Erlang language as a whole and the community, right now. The mailing lists are actually pretty good, but quite frankly, the documentation online is terrible and the Erlang interpreter is pretty rudimentary. Not to mention basic problems with the syntax and grammar of the Erlang language itself. When I was learning Erlang a few months back, I was pretty frustrated that about the only source of documentation was on erlang.org, and they.. weren't great. For instance, there needs to be a big warning right at the beginning explaining that atomic values always start with a lowercase letter and all other variables must begin with a capital letter. This must be a huge problem for other beginners (at least, I hope I assume I wasn't alone..) compounded by the unfriendliness of the error messages produced by the Erlang interpreter.

Now that I've switched over to doing as much as I can in Python, which has a great user community, wonderful docs, a healthy standard library, and a reasonably helpful interpreter.. I don't really worry about Erlang that much anymore. It would be wonderful if I could write, say, web crawlers (I work in web security) in Erlang. But the mysql support in Erlang looks alpha-quality at best, and AFAIK there's nothing even remotely similar to Python's urllib2 for basic web client functionality in Erlang.

I think it says a lot that so much attention is paid to a language that is so rough around the edges, unfriendly, and lacking in documentation. Even given all that.. the ease of use of the concurrency and message passing in Erlang is so fantastic that it almost makes up for the rough spots.

On a final note, I'd like to point out to anyone interested that I think there's a huge void out there for a language that's as easy to use and learn as Python, but with the concurrency and message passing in Erlang. It actually might not take that much work to build a network-transparent message passing interface as a Python module (I've looked into Pyro a bit.. it looks rather cumbersome and makes easy things too hard, correct me if I'm wrong). Also, modern languages need basic support for splitting up the workloads of map() or similar trivially parallelizable functions across multiple processors/cores (I know the Perl6 group was thinking about this.. not sure if this works in Parrot now or what). Basically, modern languages like Python/Perl/Ruby should really think more about making simple modules to mimic the message passing that Erlang has. Really, a little bit of code could go a long way. The Google team put together sawzall which looks kind of cool, on this note..

It's not something you can cram into an elevator pitch; erlang is an entirely different approach to parallelism. If you know how mozart-oz, smalltalk or twisted python work, you've got the basics.

Basically, processes are primitives, there's no shared memory, communication is through message passing, fault tolerance is ridiculously simple to put together, it's soft realtime, and since it was originally designed for network stuff, not only is network stuff trivially simple to write, but the syntax (once you get used to it) is basically a godsend. Throw pattern matching a la Prolog on top of that, dust with massive soft-realtime scalability which makes a joke of well-thought-of major applications (that YAWS vs Apache image comes to mind,) a soft-realtime clustered database and processes with 300 bytes of overhead and no CPU overhead when inactive (literally none,) and you have a language with such a tremendously different set of tools that any attempt to explain it without the listener actually trying the language is doomed to fall flat on its face.

In Erlang, you can run millions of processes concurrently without problems. (Linux is proud of tens of thousands, and rightfully so.) Having extra processes that are essentially free has a radical impact on design; things like work loops are no longer nessecary, since you just spin off a new process. In many ways it's akin to the unix daemon concept, except at the efficiency level you'd expect from a single compiled application. Every client gets a process. Every application feature gets a process. Every subsystem gets a process. Suddenly, applications become trees of processes pitching data back and forth in messages. Suddenly, if one goes down, its owner just restarts it, and everything is kosher.

It's not the greatest thing since sliced bread; there are a lot of things that Erlang isn't good for. However, what you're asking for is Erlang's original problem domain. This is what Erlang is for. I know, it's a pretty big time investiture to pick up a new language. Trust me: you will make all your time back in writing far shorter, far more obvious code than you did in learning the language. You can pick up the basics in 20 hours. It's a good gamble.

Developing servers becomes *really* different when you can start thinking of them as swarms.

I didn't say it was easy. I said it was possible.

In fact, it's being done now. All your points are valid challenges, but the QoS and handover stuff has been worked out. Power is certainly an issue for Wi-Fi, but given that you're most likely to use that at home or at work where you can recharge it's a solvable issue. Alternatively, you could start connecting GSM Pico-cells to local networks as Boeing and Airbus are doing for in flight calling.

The enduring problem is, the carriers are still looking to route the entire call back through their network (and hence charge you for it). That's just not necessary and I look forward to the day they lose their grip.

I couldn't find find anywhere in the article that said he didn't use the internet, and I know that some people *do* access the Internet on their old Commodores.

A quick search immediately reveals 2 browsers for the C-64:
- Hyperlink ( http://www.armory.com/~spectre/cwi/hl/ )
- Contiki ( http://www.sics.se/~adam/contiki/apps/webbrowser.h tml ) ...and there are probably more.

Actually, as a point of amusement, the one in Contiki does.

I cannot speculate, but I can look at what people are doing today. One thing that I have noticed, is the widespread research into, with compelling arguments, for massively multithreaded programming techniques. See Erlang for example. It is designed right from the beginning for this sort of problem - high throughput, high reliability, high uptime telephony networks.

As a rough benchmark, someone's got this.

That's an order of magnitude increase in "performance" (depends on what you mean by performance". I thought I'll do a casual informal test of my own, with a decent static file size (instead of the 1 byte used in that benchmark)

Server Software: Yaws/1.56
Document Length: 402 bytes

Concurrency Level: 500
Time taken for tests: 8.480740 seconds
Complete requests: 5000
Requests per second: 589.57 [#/sec] (mean)
Time per request: 848.074 [ms] (mean)

Server Software: Apache/2.0.54
Document Length: 402 bytes

Concurrency Level: 500
Time taken for tests: 29.787216 seconds
Complete requests: 5000
Requests per second: 167.86 [#/sec] (mean)
Time per request: 2978.722 [ms] (mean)

Output edited to get past lameness filter.

Err crap, I could have sworn the first time I tried this, when Yaws was first installed, its performance was worse! Oh well, perhaps it's something I've inadvertently done since then. Could have been due to my computer reboot (this is a desktop PC). It seems I've proven my point, although I was trying to disprove it. Standard caveats regarding benchmarks apply. Both servers are default Ubuntu installs with no configuration changes - I didn't compile anything manually.

Additionally it has also been noted that:

> Linus Torvalds: 100k threads at once is crazy Using Posix style threads, I'd have to agree. Posix threads were just not designed with this level of usage in mind. Which is why concurrent lanugages like Erlang and Mozart/Oz don't use Posix threads.

Well, that's where it could be headed anyway - a multiprocessor system with green threads (ie simulated threads, like Java ones) implementing massive concurency and redundancy. Some prototypes for systems like this are already available, and being used. Cheers.

Perhaps you would be interested in the Contiki OS, which has already been ported to the Apple ][ as well as wide variety of other old (mostly 8-bit) machines. http://www.sics.se/~adam/contiki/

Hell, there is webserver software for the Commodore 64. Why not a Cell Phone?

> Is BIND really that pathetic, or are they just not using it correctly?

Here's a performance comparison of the ubiquitous Apache web server with Yaws, an Erlang-based web server. (Erlang is a programming language and virtual machine designed for distributed processing.) To summarize, "Apache dies at about 4,000 parallel sessions. Yaws is still functioning at over 80,000 parallel connections." The author goes on to speculate that the reason Apache dies so quickly is due to limitations in the host operating system.

If Erlang can keep a web server going under nearly infinite load, imagine what it could do for DNS.

As a basic sort of testing phase, do it all on one computer. This eliminates all possible network errors that can occur. I'm assuming this is meant to be huge so maybe the bugs you speak of result from multiple machines fouling each other up. Either way, let's talk debugging strategies!

Also, as I recall from my days of drudgery at college, create tons of output.

So I will suggest as a preliminary requirement that you create a nice logging system (if you haven't done so already). I haven't written much C# so I'm going to be talking abstractly. Hopefully the rest of Slashdot can help with the specifics to C#. Now, what I mean is that you should create a class that just creates an output log file that you can read for output later. I don't mean to put a message for every packet sent but maybe it wouldn't hurt to put a message for each stream or connection opened. It's going to help for you to generate random IDs for each call and to put the destination/receiving IP:Port in your log. This would most likely be helpful with a server. It also will be helpful to store printlns in your code (redirect standard out to the logger).

Now use this on every machine in the system. If one machine should start to give you problems, create a mutual exclusion on this log (or put all of the log entries in critical regions). In Java, you can use object locks or the synchronized keyword--in C# I'm pretty sure they have something similar. Just because it's not a GUI doesn't mean you can't record output.

Just a friendly warning, time stamping is usually worthless unless you have a logical network (i.e. a Lamport Clock) clock scheme set up (which usually requires lots of time on one's hands). You could shoot for an NTP server but I wouldn't trust the accuracy past 500 ms. If you absolutely need a clock scheme, I recommend having one machine on the network tick tock an increasing number that is reflected in all the logs. Make the time between ticks adjustable--this way you'll be able to check out events roughly relevant to these ticks (assuming the time it takes to get there is similar).

In the end, your best tool is your brain. Designing tests and double checking the logs on each machine to see that the linear time sequence of relative events is correct. Logic will be your only friend in this journey. Don't be afraid to kick off more threads on the client side if they don't need to share resources. If you have a server side, be careful in how many threads you have and make sure you realize what memory scope they're limited to.

For the love of god, if you use ports--don't forget to free them when you're done using them!

Unfortunately, Nornir is not OSS ... yet. Their papers may be of use to you, however. If you're having problems with packets on either end, use my good friend ethereal.

Good luck! Happy debugging!

As a basic sort of testing phase, do it all on one computer. This eliminates all possible network errors that can occur. I'm assuming this is meant to be huge so maybe the bugs you speak of result from multiple machines fouling each other up. Either way, let's talk debugging strategies!

Also, as I recall from my days of drudgery at college, create tons of output.

So I will suggest as a preliminary requirement that you create a nice logging system (if you haven't done so already). I haven't written much C# so I'm going to be talking abstractly. Hopefully the rest of Slashdot can help with the specifics to C#. Now, what I mean is that you should create a class that just creates an output log file that you can read for output later. I don't mean to put a message for every packet sent but maybe it wouldn't hurt to put a message for each stream or connection opened. It's going to help for you to generate random IDs for each call and to put the destination/receiving IP:Port in your log. This would most likely be helpful with a server. It also will be helpful to store printlns in your code (redirect standard out to the logger).

Now use this on every machine in the system. If one machine should start to give you problems, create a mutual exclusion on this log (or put all of the log entries in critical regions). In Java, you can use object locks or the synchronized keyword--in C# I'm pretty sure they have something similar. Just because it's not a GUI doesn't mean you can't record output.

Just a friendly warning, time stamping is usually worthless unless you have a logical network (i.e. a Lamport Clock) clock scheme set up (which usually requires lots of time on one's hands). You could shoot for an NTP server but I wouldn't trust the accuracy past 500 ms. If you absolutely need a clock scheme, I recommend having one machine on the network tick tock an increasing number that is reflected in all the logs. Make the time between ticks adjustable--this way you'll be able to check out events roughly relevant to these ticks (assuming the time it takes to get there is similar).

In the end, your best tool is your brain. Designing tests and double checking the logs on each machine to see that the linear time sequence of relative events is correct. Logic will be your only friend in this journey. Don't be afraid to kick off more threads on the client side if they don't need to share resources. If you have a server side, be careful in how many threads you have and make sure you realize what memory scope they're limited to.

For the love of god, if you use ports--don't forget to free them when you're done using them!

Unfortunately, Nornir is not OSS ... yet. Their papers may be of use to you, however. If you're having problems with packets on either end, use my good friend ethereal.

Good luck! Happy debugging!

So what he needs to do is develop a design that is robust in the face of errors. In other words, it needs to be fault tolerant. There are well-known design practices for doing this (checkpoints, watchdogs, rollbacks, etc.) as well as design patterns for robust distributed computation (see, for one example, Joe Armstrong's thesis on making reliable systems in the presence of software errors.

No, the situation the OP is in is not ideal. But it's also not impossible to work with, and there are techniques that can help him to get closer to achieving his goals within the constraints placed upon him.

Wow. An entire thread devoted to this question, and so far this is the only answer that actually addresses the problem. Every other suggestions seems to be "changes languages", or "here's how to avoid bugs".

Anyway, let's talk specifics here. For the theoretical end of software fault tolerance, you can get a quick overview here or here.

In terms of practicalities, I know of an older fault tolerance library for Unix that includes watchdog, checkpointing, and replication utilities, and was created by AT&T (details and downloads here). A newer version appears to be available for Windows under the name SwiFT. Disclaimer: I haven't actually used either of these, and they both seem a little old. But I don't know of anything newer that isn't a proprietary in-house solution.

Finally, in terms of general design patterns for fault-tolerant distributed systems, you can't go past Joe Armstrong's PhD thesis, "Making reliable systems in the presence of software errors". While it's mostly about Erlang, many of the ideas he presents are readily applicable to other languages too.

The Swedish Antipiratbyrån enforced their ISP control rights today, not going to the police but instead contacting the Swedish news show 'Rapport' disclosing that they'd found a major hub on top of the piracy chain. The gist was that the server running the hub was placed at SICS, the Swedish Institute of Computer Science, renown research institute partially funded by the Swedish state.

With the uIP stack. As long as best is defined as: small with a BSD licence :)

Contiki does more in about 30k of ram.

They can download all the software they want, surf the web and write their email all on the same system they use for their data analysis without worry and I'm not getting calls or visits to my office saying "Ummmmmmm. I think my system is infected"

You could accomplish the same thing with apple //. The hardware is a lot cheaper too.

This just proves, once again... that the Amiga is the most secure platform out there.

Hah! Only until Contiki gets h4><0r3d!

;-)

/slinks off to h4><0r an 8-bit browser...

Thank god I use Contiki!

Contiki already runs on the C-64. It's not Linux, but it does VNC.

no. but there is a nice modern operating system for 8bit computers, including the c64. it has tcp and web browser etc

http://www.sics.se/~adam/contiki/

The Cell is the thing for number crunching and pro applications where they are willing to spend the time optimizing for every single CPU, but for normal developers it is a step back.

1) Unhook your Windows PC
2) Grab you C64 out of the garage
3) http://www.sics.se/~adam/contiki/

How can you make a virus with only 64K of address space?

In reality, this site is hosted on an Amiga.

Hey...That is obviously wrong, but it's an easy mistake to make. Not every Commodore is an Amiga.

I'm writing this on my Amiga, with Apache running comfortably on it, actually. It pumps out large files too (around 100 MB), with upstream bandwith the limiting factor to speed.

You've confused the Amiga with the Commodore 64, which actually does have a webserver: Contiki ;-)

Actually, there are Commodore 64s that are online, both client-side and server-side. Contiki gives you a text web browser, an irc client, a web server, and more.

You could connect with a modem, or with an ethernet plug with the Retro Replay expansion.

Amazingly, for such a popular method of 'communication' between and within applications, XML is admitted by most to be rather flawed and bulky...

Universal Binary Format has been around for a few years now, and it includes everything binary XML would have, but in a cleaner, more well-thought out form, in addition to having an extra higher-level protocol for inter-machine transport and security issues.

I read the arguments about Isolation - but sorry, isolation isn't enough.

To make things that never fail you need more than one computer!

The minimal configuration is TWO computers (sorry for shouting) and even that won't work if both computers fail.

This means you need to do distributed computing - whether you like it or not.

Stuff that never stops => more than one computer => distributed computing.

It also implies NO SHARED DATA STRUCTURES (imagine me hitting the keyboard here) - why? - think about it. Computer A has a pointer to a data structuire on computer B - computer B now crashes - ooops.

So how far have we come? - you need two or more computers, and no shared data structure (oh, and by the way, no sharing implies EVERYTHING MUST BE COPIED) - so you have to copy everything you need to do crash recovery to both machines involved.

This is very definately NOT how java was designed. Threads SHARE resources - so you have to use one style of programming when using two threads on the same machine but a completely different style of porgramming when using two threads on two different machines - some people might like this - I don't.

Oh and what more? - stable storage - what's that? Stable storage is storage which survives a crash! You need that as well.

I think (I'm not really sure) That there are actually 6 different things you need to do to make a fault tolerent system (see pages 27-28) of [1] - isolation in one of them.

If you want to make fault-tolerent system I'd suggest to read [1] (it's free) - then download [2] and off you go - it's easy.

Using [2] We have made some pretty reliable systems - as far as I know some of them have never stopped :-)

Cheers

/Joe

• [1] Making relaible systems in the presence of Software errors
• [2] www.erlang.org

It was really fun reading this article as isolation as described in this article has been one of the founding principle of the Erlang VM. Erlang is a concurrency oriented langage created to support the development of robust scalable fault-tolerant applications.

I strongly recommand reading Joe Armstrong thesis. This is very enligthning regarding this topic and this is real world feedback:

armstrong_thesis.pdf

Fortunately, Erlang has been designed from the ground-up for robustness. All feature of Erlang are designed to achieve the robustness goal (Concurrency model, functional programming, error handling, supervisor and worker mechanisms). This is precisely why it will be very difficul to achieve with Java, if even possible.

I hope this helps,

--
Mickaël Rémond
http://www.erlang-projects.org/

No, it doesn't run Linux, but it does run Contiki!