Slashdot Mirror

a.k.a., konqueror.

*ducks!*

But seriously folks, you'd probably do better to start with links, w3m, arachne, dillo, Contiki, HyperLink, The Wave -- any codebase that was designed to be relatively lightweight from the start. Or, especially in the case of the last three, probably just write a new one. :(

Now on my desktop, I use konqueror because it's snappy; of course the mobile device game is totally different, but I'd expect that people would want some of the same things--notably, a responsive, un-bloated browser.

Contiki - multitasking kernel, TCP/IP stack, GUI, themeable window system, web server, web browser, etc. Runs in 40k RAM (yes, only 40960 bytes!). That's efficient coding.

http://contiki-demo.sics.se/

Missing choice (you insensitive clods)! I only use microVNC! You know, for those times when you simply MUST remotely connect to the 8-bit microcontroller in your toaster when you're at work.

Contiki !

=Smidge=

Seems like the uIP embedded TCP/IP stack would be ideal for this, as it is very small and portable. Also, it apparently already has been ported to and run on laptop keyboard microcontrollers. How about that kind of sniffer virus!

Also look at the Contiki OS, which even runs on the original GameBoy.

Now with a C compiler available, how about building an Ethernet interface and porting the Contiki OS to iy? A Contiki port would bring TCP/IP networking, multitasking and a bunch of other cool stuff to the HP. Contiki has already been ported to a lot of weird stuff, like the GBA and the C64, so it would probably work well on the HP.

there's a research project about sensor networks going on at the Swedish Institute for Computer Science (SICS): http://www.sics.se/cna/dtnsn/. one of the researchers, Adam Dunkels, is the guy who posted a TCP/IP stack written in PHP a while ago.

I think this is a cool thing, but I wouldn't mind buying a remote control based on the Contiki OS instead. Contiki also allows remote administration over the net, and also has pretty icons and a GUI. Given the requirements of Contiki, the device would not need to have megabytes of memory and could be made significantly cheaper. Perhaps a $7 network-enabled remote control would see a wider audience?

There is (was?) a project at KTH/SiCS in stockholm with a similar concept called GeoNotes. This link is unfortunately not working right now, here is a description of the concept.

Heh, actually I have forwarded port 80 to the Commodore before (using the Contiki web server and RR-Net ethernet adaptor), but in this case the graphic was several times larger than a CBM-format 5.25" disk. :)

Those of use using the Contiki web browser as our primary browser are still safe! Phew!

53 years, and still no sign of a port of Contiki. Sigh, when will we be able to Slashdot the first UNIVAC web server?...

It looks like the author of the server posted a Slashdot FAQ to answer questions posed here. Too bad it's not terribly informative and contains a lot of those generic "frequently asked questions" that no one would actually ever ask. Maybe it'll keep the Negative Nellies off his back though. Hint: He knows it's an extremely limited webserver.

The TCP/IP stack is intensionally very simple - this is just a proof-of-concept demo and nowhere did I claim it to be RFC compliant or of production quality. I don't think that PHP is the right language for writing a TCP/IP stack for production use. If you are interested in a fully functional but still very small TCP/IP stack, you should take a look at my uIP stack instead. It has full support for IP fragment reassembly and has an RFC-compliant TCP and still fits in only a few kilobytes of code space.

(And, by the way, the FIN + PSH + ACK flag combination is perfectly legal.)

I am the author of this and I must point out that the phpstack server is actually still running after over two hours of slashdotting! It is extremely slow, however, because of the insane amount of IP packets that have to traverse the 115200 bps serial line that connects the server with the rest of the world. The front page of the server currently reports that it has served 13157 visitors.

A lot of people that comment here focus solely on the web server part of this software and completely miss the novel part in this: the TCP/IP stack. Writing a simple web server is dead easy. To the best of my knowledge, however, nobody has been stupid enough to write a TCP/IP stack in PHP before :-). The web server running on top of the stack is really simple and can be seen as the equivalent of the "netcat" web server someone suggested.

The TCP/IP stack is intensionally extremely simplified (or "half-baked", if you wish) and tailored to the specific needs of the simple web server. Someone implied that the reason for the simplifications was that I maybe hadn't "figured out" how to handle fragmented packets. Well, it does not have to do with packet fragmentation (IP fragmentation is not that much of an issue today), but with the TCP receiver not trying to put together incoming TCP segments into a stream. Interested people could take a look at my uIP or lwIP TCP/IP stacks to see how to solve these problems in the general case. I have also written a paper that discuss issues with reducing TCP and IP in more detail.

Of course, there are also the standard "this guy should get a life" comments. I always find it amusing to see such comments being posted only 10 minutes after the article hit the Slashdot front page, on a Saturday. I'm not the only one in need of a life, it seems :-)

Finally, all of this is just a quick hack made solely for fun (and in part to learn more about PHP). I submitted it to Slashdot simply because I enjoy seeing articles like this myself. From the insane amount of traffic to my demo server, it seems that quite a lot of other people find it interesting as well :-)

I am the author of this and I must point out that the phpstack server is actually still running after over two hours of slashdotting! It is extremely slow, however, because of the insane amount of IP packets that have to traverse the 115200 bps serial line that connects the server with the rest of the world. The front page of the server currently reports that it has served 13157 visitors.

A lot of people that comment here focus solely on the web server part of this software and completely miss the novel part in this: the TCP/IP stack. Writing a simple web server is dead easy. To the best of my knowledge, however, nobody has been stupid enough to write a TCP/IP stack in PHP before :-). The web server running on top of the stack is really simple and can be seen as the equivalent of the "netcat" web server someone suggested.

The TCP/IP stack is intensionally extremely simplified (or "half-baked", if you wish) and tailored to the specific needs of the simple web server. Someone implied that the reason for the simplifications was that I maybe hadn't "figured out" how to handle fragmented packets. Well, it does not have to do with packet fragmentation (IP fragmentation is not that much of an issue today), but with the TCP receiver not trying to put together incoming TCP segments into a stream. Interested people could take a look at my uIP or lwIP TCP/IP stacks to see how to solve these problems in the general case. I have also written a paper that discuss issues with reducing TCP and IP in more detail.

Of course, there are also the standard "this guy should get a life" comments. I always find it amusing to see such comments being posted only 10 minutes after the article hit the Slashdot front page, on a Saturday. I'm not the only one in need of a life, it seems :-)

Finally, all of this is just a quick hack made solely for fun (and in part to learn more about PHP). I submitted it to Slashdot simply because I enjoy seeing articles like this myself. From the insane amount of traffic to my demo server, it seems that quite a lot of other people find it interesting as well :-)

I am the author of this and I must point out that the phpstack server is actually still running after over two hours of slashdotting! It is extremely slow, however, because of the insane amount of IP packets that have to traverse the 115200 bps serial line that connects the server with the rest of the world. The front page of the server currently reports that it has served 13157 visitors.

A lot of people that comment here focus solely on the web server part of this software and completely miss the novel part in this: the TCP/IP stack. Writing a simple web server is dead easy. To the best of my knowledge, however, nobody has been stupid enough to write a TCP/IP stack in PHP before :-). The web server running on top of the stack is really simple and can be seen as the equivalent of the "netcat" web server someone suggested.

The TCP/IP stack is intensionally extremely simplified (or "half-baked", if you wish) and tailored to the specific needs of the simple web server. Someone implied that the reason for the simplifications was that I maybe hadn't "figured out" how to handle fragmented packets. Well, it does not have to do with packet fragmentation (IP fragmentation is not that much of an issue today), but with the TCP receiver not trying to put together incoming TCP segments into a stream. Interested people could take a look at my uIP or lwIP TCP/IP stacks to see how to solve these problems in the general case. I have also written a paper that discuss issues with reducing TCP and IP in more detail.

Of course, there are also the standard "this guy should get a life" comments. I always find it amusing to see such comments being posted only 10 minutes after the article hit the Slashdot front page, on a Saturday. I'm not the only one in need of a life, it seems :-)

Finally, all of this is just a quick hack made solely for fun (and in part to learn more about PHP). I submitted it to Slashdot simply because I enjoy seeing articles like this myself. From the insane amount of traffic to my demo server, it seems that quite a lot of other people find it interesting as well :-)

I couldn't have been more impressed with the VNC server for the OS [sic].

Man, that's a sic and a sick. Impressive stuff. That's enough for me to really start jones'n to build that ethernet port on a breadboard and give it a shot.

Use your Apple IIe from nearly any box connected by broadband from anywhere in the world. Man, the 21st century rocks! ;^)

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.

Linux probably would a bit too large to fit, but a port of Contiki might be worth waiting for, given their track record... Now if only someone would care to make a mechanical Ethernet NIC and we could build a fully mechanical webserver. You wouldn't be able to stand the noise a slashdotting of that would make!

None of the readers seem to anything about it...

A few points:
* interpreted languages nowadays tend to compile to native code
* the compiler or run time is better at optimising than you are
* performance is not the same as scalability, a scalable architecture is more importantant than Mips (Mips are cheap commodities which you buy in inexpensive boxes from HP or Dell - if your architecture supports it)
* most real life systems have latencies (io, kernel activities, screen painting) which are only tangentially related to the grunt of your piece of code (see architecture)
* Erlang is uber scalable, designed to build reliable high performance systems. It provides its own (very lightweight) concurrency and means the developer doesn't use expensive OS process and thread spawning and doesn't have to worry about managing threads and synchronisation.

Check out the Yaws (yet another web server) versus Apache benchmarks for throughput and concurrency.

Erlang systems also stay up. The main BT telephony system only had 31ms downtime in its first year (see here (page 30).

The reason why functional programming languages (not just Haskell) aren't popular is a bit of a Catch-22 situation. Most people try to learn a new language because it adds value to their resume or because something they're working on demands it. In the former case they always lean towards the so called mainstream languages - C/C++/C#/Java/... In the latter case, they probably don't care which language they're forced to learn and abandon it once their work is done. So a language doesn't get adopted unless it goes mainstream. But for a language like Haskell, it's difficult to go mainstream unless it gets adopted.

This does not in any way mean that an implementation of an idea in a functional language is necessarily slower than one in a say C/C++. See for e.g. Yaws . Phil Wadler has some information on functional language use in industry here. Galois Connections uses functional languages like Haskell/ML and there are several companies which use Erlang.

Maybe it's time to break from the lemming-like rush to format absolutely everything in XML.

If you want a concise, readily-parsed alternative, consider UBF - don't let the title of the paper throw you; it's really about a lean alternative to XML.

Or just enjoy some alternative viewpoints on the subject at the Portland Pattern Repository's XML Sucks page.

>It always cracks me up when people invoke these languages that never occur outside of an academic setting.

I guess I should have learned Cobol, right? Leaving C/C++ out, for the sake of the argument, I did two years of coding in Perl + Prolog at a full-text retrieval software company. Currently employed at a supply chain & logistics software company using a blend of C++ & Sicstus + constraint logic programming module.

OK. I've never seen a mature OS written in Modula (some parts in Arthur appear to be, but that could harly be considered a mature OS, right?) and Haskell, Gofer, Miranda are probably just too hard for the average MSCE drone. But please stop whining about not being able to find a job that's more challenging than writing ASP, VB, Java, C#, PHP, Perl, Cobol... interfaces to some SQL database. If you feel your graduate diploma was a waste of time, please look around: There lots of good paying interesting jobs out there.

--
There are two ways of constructing a software design: One way is to make is so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare

Now this would require a sharp dividing line between executable code and data (at least for user programs - who knows what the OS is doing under the hood?). Data would then be serialized to UBF (mostly because XML is too fat). But this is actually a good thing - this would enable a painless move to the much more efficient Harvard architecture.

In practice, I think such system would probably suck in many ways; a lot of it would have to do with disallowing assembly. What is a much more realistic alternative (it's worked on some of the most successful systems ever built!) is to combine a powerful, interactive and unrestricted language and open-source software with technically sophisticated users. ITS is the paragon of this approach.

Dynamic web pages are slow in general, which is probably what the original post was referring to.

PHP is also fairly slow as a language; it was the second slowest language in Doug Bagley's computer language shootout, only winning over shell scripting.

Not that I think the shootout is a particularly good comparison in terms of methodology, but it seems fairly consistent with my own experience with the languages.

Of course raw performance isn't always the most important, Erlang isn't very fast, but has fairly impressive multithreading. Of course Oz and Concurrent ML have even faster multithreading, and the latter is also fast as a language.

Some people are working on utilizing e.g. solar power for wireless sensor networks. The PDF files on this page discuss these ideas and are quite interesting, for instance.

I'd say ditch XML and use UBF instead! It supports binary objects and is proveably three times faster to parse than XML.

Athlon 64 can run 99 percent of Commodore 64 software in emulation, including the C=64 version of the Contiki OS. In addition, it can probably run almost all these other ports.

You want native? If the Athlon 64 processor and chipset can boot up as a normal x86, it can run Contiki for PC DOS.

Microbenchmarks about string concatenation and method calling are mostly irrelevant. What's important is too see how an implementation scales up to huge programs, say 500,000 lines of code and 1GB of data. There have been plenty of cases of fast languages not scaling up well (like C++), because you have to add so much cruft to hande the kind of problems you hit at that level, and much "slower" languages outrunning them because they were architected for that kind of problem.

One interesting case is Yet Another Web Server (YAWS), which is written in an interpreted language and completely blows the socks off of Apache under high load.

Here's a link to a screenshot of an old /. entry about said OS. It would've been cool if the "live" VNC shot was of this slashdot discussion, eh?

File statistics
Connections
Running processes

File statistics
Connections
Running processes

File statistics
Connections
Running processes

Click here and you can watch an Ethernut get flooded with connections as it gets Slashdotted! Better hurry! Slashdotting is already in progress! :)

Erlang makes writing applications like this much much easier than in any other language or framework I've seen.

Check out this tutoral on making a fault-tolerant server in Erlang.

...something Yahoo fails to accomplish.

See Contiki.

http://www.sics.se/~joe/tutorials/robust_server/ro bust_server.html.

Regards,
Marc

Writing a robust program in Erlang is extremely simple by using supervisors and following design principles like these. For example, my Erlang IRC bot is near impossible to completely crash. If the server connection dies, there's a supervisor that'll keep trying to get it back up; All the while the other processes of the bot have no idea there's no connection -- they don't need to know. If I've written a faulty module and the code misbehaves, only that single process is affected. If possible, a process that has crashed will be automatically restarted and operations resume as if nothing had happened.

Hot-swapping of code allows me to debug the bot without restarting it. If I discover a bug in the irc parsing routines, I simply fix it in the code, recompile, and reload the offending module -- while the bot is running. The new code replaces the old, and it just works.

There's plenty more, but I would suggest checking Erlang's website and reading the FAQ and examples. Oh, and here's a nifty benchmark :)

No, this isn't a joke.. =)

I haven't touched uIP myself, but we're using lwIP (its big brother) in KallistiOS, the DC hobbyist OS project. Adam sent this to me pretty recently and I thought it kicked ass beyond belief:

lwIP will be used in the post-production of Lord of the Rings 2 and 3
-Dan Potter

You can start using IPv6 right now even if your ISP only supports IPv6, by tunneling it using 6to4 to another 6to4 machine acting as gateway. The 6to4 tunneling protocol is in the kernel as of at least 2.4.1 (earlier version than that I believe you need to apply a patch or two). If you live in Sweden (like me), check out SICS' 6to4 gateway. They have connections to the 6bone and to several ISPs (it is recommended that you try one of those first).
---

An IPv4 stack needn't be that large. There are many IPv4 implementations out there that are suitable for small devices. My own IPv4 stack lwIP is between 10k and 20k (depending on your configuration) and is optimized for using low amounts of RAM. It has hooks for implementing IPv6 as well, and the extra code will probably not be that large.

Moreover, there is no need to implement all of IPv6 in a small device, only the bare bones functionality should suffice.

As a side note, CPUs are getting faster and less power consuming, and memory is getting cheaper so in the near future our cell phones will be nearly as powerful as yesterday's PCs.

Comparing Java to Mozart, a standard consumer-producer multithreaded application running within:

The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 72 lines
Mozart code 24 lines

Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 168 lines
Mozart code 30 lines

DESCRIPTION

The Mozart threading model uses logic variables to create synchronization between threads. This can be viewed as automatic construction of dataflow dependency graphs, or as what logic programming calls "AND-parallelism". Either way, synchronization falls out of functional or relational dependency inherent in the semantics of the program rather than being an additional thing for the application programmer have to write and therefore possibly write wrong. Constraints may be added to logic variables consistent with prior constraints but they may not be deconstrained once successfully constrained.

Comparing Java to Mozart, a simple consumer-producer multithreaded application running within:

The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 108 lines
Mozart code 28 lines

Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 220 lines
Mozart code 32 lines

(See ref 1.)

IMPLEMENTATION

Mozart's threading model has been implemented for other languages (see ref 2). Central to this model is Mozart's "computation space" construct. Computation spaces are heirarchical collections of threads and logic variables. Each thread and each logic variable belongs to exactly one computation space. When a logic variable is introduced that is "local" to a thread, it spawns a new computation space. "local" as used herein has the same scoping as the Perl "local" keyword: upward visibilty and downward invisibility. When a thread attempts to add a binding (constraint) on a logic variable that is inconsistent with prior bindings, the thread fails thus raising the associated exception. (See ref 3)

For simplicity of initial implementation, constraints could be limited to simple single-assignment dataflow variables and later expanded to numeric relations like >, &lt and != and might someday become as sophisticated as performing regular expression algebra to determine consistentcy of adding regular expression constraints to variables.

REFERENCES
(1) "An Example of Programming in Mozart versus Java" by Per Brand (http://www.sics.se/~perbrand/javaVSMozart/)
(2) "Efficient Logic Variables for Distributed Computing" by Haridi, Van Roy, Brand, Mehl, Scheidhauer and Smolka http://www.mozart-oz.org/papers/abstracts/TOPLAS99 .html
(3) "Computation Spaces" from the Mozart documentation http://www.mozart-oz.org/documentation/tutorial/no de12.html#label65

Just normal IP multicast does not have any guaranteed delivery, so that is not good enough if you need to have a recieved copy where every bit is exactly the same as the original. For that you need Reliable Multicast, a protocol placed above IP multicast that takes care of retransmissions etc.

There is actualy some atempts at distributed filesystems using multicast, one example is JetFile. I guess something like this could be used to sync ftp mirrors etc.

Um, I'm not sure I should be saying this, but what the heck: have you seen DIVE?. If you hit that link, you'll get their front page featuring a collage of screenshots. Look close, and you'll see standard X apps textured into a 3D world. Scroll down, click "pretty pictures", and you'll see more...