According to the docs it's using Linux on a smartphone class ARM (AT91SAM9G20) with the ethernet MAC on-chip http://rascalmicro.com/docs/software-guts.html

The hardware should have no problem maxing out its own network connection. Whether the application software can keep up would be my question.

It's clearly going to perform much better than a nanode http://nanode.eu/ Which is being pitched as an HTTP enabled sensor node, still relying on Pachube or other cloud services.

But, the Rascal may have enough grunt to run its own services. I wonder how capable it would be of servicing many simultaneous connections? (running Twisted/Node/etc.) Perhaps RAM is the limiting factor?

(Hi Joby. Why am I acquainted with everyone in this thread?)

I think you're right that RAM is the limiting factor. Right now, the uWSGI application server is using ~30% of the CPU and 50% of RAM. Nginx, which is serving the static files, is using very little CPU and maybe 15% of the RAM, which is the same as when Nginx is idle. It's been on the front page of HN for about an hour now, and so far as I can tell, it's surviving fine.

These lights and the story behind them are interesting, but weathering the flood you'll get if this makes it to the front page is the real story. http://www.rascalmicro.com claims that "The Rascal is powerful enough to handle real web traffic...", and HN has been known to take down much larger hardware.

I signed up for the mailing list last year, and I'm still waiting eagerly for launch! The last blog post on http://pingswept.org/ and https://twitter.com/#!/rascalmicro both look promising.

(Hi Kevin.)

Thanks for the enthusiasm.

I'm watching the logs stream via tail -f right now, and the Rascal is holding up OK. The post is near the bottom of the front page now, and it's handling around 10 hits per second fine. The Rascal is serving both the light control and all the background pages ("what", "story", "technicals") as well. I'm actually more worried about the cable connection to my house than the Rascal. (Eerik put the angerlights in my basement while he moves to California. By the way, he's looking for a job: http://www.linkedin.com/profile/view?id=89147645)

More beta units are on the way-- the hardware beta was successful; software testing is underway.

I'll write up a post-mortem on the HN traffic and put it on the Rascal blog (http://rascalmicro.com/blog/) in a couple days.

I want to make the bulbs die remotely.. Can we do it with a script toggling them on and off in a rapid rate?

You're welcome to try. The problem is that the Rascal fetches a new image from the webcam after every click. In order to make sure that the bulbs have turned on (or off) before the image is updated, Eerik added a 1 second delay in the loop. I think this makes it impossible to toggle the bulbs at more than around 0.5 Hz (1 second on, 1 second off).

If it weren't for the delay, you could hit 300 Hz or so. You could probably even dim the bulbs with PWM if you wanted.

To kill a light bulb, it may well be more effective to cycle them at 0.5 than at 300 Hz, anyway-- you get more thermal cycling, and maybe even some interesting dynamics from the relay bouncing.

Started getting some corrupted images partway through, at roughly 1:00. Possible meltdown?

http://i.imgur.com/Eme3D.png http://i.stack.imgur.com/bID6D.png http://i.stack.imgur.com/ErM6T.png

(confirmed by myself and another user in the http://electronics.stackexchange.com chat room).

Mysterious. I can't replicate that from here, at least with some idle clicking.

The traffic has dropped off substantially since earlier today. The Rascal served around 200,000 hits over the course of around 2 hours on the front page. I've been logged in remotely the whole time, so there can't have been any reboots, or my SSH session would have been terminated.

Judging by the process id's of the servers, I don't think any of them have been restarted.

The error log looks pretty clean. There's huge pile of errors from a misnamed font file, but that's minor. Other than that, there are just two errors that look like this:

  readv() failed (104: Unknown error) while reading upstream, client:
  80.176.154.87, server: localhost, request: "POST /toggleEerik HTTP/1.1",
  upstream: "uwsgi://127.0.0.1:5000", host: "209.6.42.115:82"

It's a neat project, technically. But...

"If one turned on one's anger light in a fit of frustration, it was useful as a reminder later in the day to remain angry."

I'm all for finding healthy ways to express anger, but actively holding on to anger that would have naturally dissipated seems like a great way to transform yourself into a perpetually bitter person.

The site is broken at my 1024 pixel screen width (netbook). About a quarter of the text exits stage left. It's easier to read the content via view-source.

EDIT: The problem is your 1280px width declaration in style.css's rascalcontent class. Guessing this will screw up smart phones too.

That's curious-- in my browser, the picture gets cropped, but the text remains visible. What browser and OS are you using?

EDIT: Thanks for the 1280px info.

Chrome 12.0.742.124. Arch Linux. Screen cap: http://i.imgur.com/4vEl3.png

Ah, you meant the text on the sub-pages-- I thought you meant the links on the front page.

EDIT: OK, fixed, I think.

All is readable for me now. Thanks!

It reminds me an episode from Big Bang Theory.