Splashpower started in 2001: http://en.wikipedia.org/wiki/Splashpower

I actually saw one of their demonstrations and it was cool. The pad was just a slightly thick mousepad like device, and you could put multiple phones of different types on it at the same time and at any orientation. They had modified battery modules to contain their own chip which did the inductive pick up and regulation. They said their goal was to get the chip built into devices by default, although unless the chip was very cheap, I suspect this would have been difficult to include in cost sensitive mobile phones and iPods.

There's a similar lego plotter in this book: http://www.clarkonline.org/william/mapyor/index.html

The book describes using some large lego wheels to form a drum around which the paper was attached, and how to form a small electro magnet around a bolt through a technic lego plate to pull the pen towards the drum. The pen itself was suspended between two lego axles on a butterfly pin. The whole magnet head assembly could pinion left and right using an improvised lego rotary counter to measure progress with a similar block to rotate the drum.

I had the Sinclair Spectrum version of the book as a child and an IO box of relays. I never made the printer, but made lots of other devices.

There's some inside pictures of the book here: http://www.hexapodrobot.com/forum/viewtopic.php?f=35&t=318

A PDF of the book is here: http://www.worldofspectrum.org/infoseekid.cgi?id=2000479

smart enough to make these idiot companies with closed-source encryption

It's often overlooked that GSM development started in 1982. At that time computing power was a fraction of what it is now and DSPs, rather than dedicated logic used in today's chipsets, would be used for the first implementations of this new technology. Mobile phones are also very power sensitive devices - battery life is very important.

So given these pressures, some corners had to be cut to make the system workable on the available technology. This lead to the A5 algorithms being both proprietary and somewhat lightweight given the limited computing resources in a mobile phone. Due to the huge success of GSM and the number of handsets out there, it rapidly becomes very difficult to change the standard in such a fundamental manner. 3G is one attempt to upgrade the GSM standards and brings in new ciphers based upon an existing published standard, but even that has taken a long time to get traction and GSM is still very widely available.

So to say these companies are idiots is somewhat ignorant of the historical practicalities required to make GSM a success.

Doesn't Chromium use GTK?

3.7 stands for a feature set on the Firefox roadmap.

Skipping that number signifies that the planned release has changed form. Avoiding use of that number then neatly avoids confusion about what the new planned releases will contain since Firefox 3.7 already has an attached meaning. It also allows retrospective discussion of what was planned for 3.7; useful if the roadmap is being updated.

If you don't have a published roadmap with promised features, keeping the next release as n + 1 is no problem.

Yeah - I'd be surprise if you could damage the CPU in the way described in the original post.

There's a bunch about thermal monitoring and control from Intel here:

http://www.intel.com/technology/itj/2006/volume10issue02/art01_intro_to_core_duo/p06_thermal_design_point.htm

The relevant bit is:

"The power monitor continuously tracks the die temperature. If the temperature reaches the maximum allowed value, a throttle mechanism is initiated. A multi-level tracking algorithm is implemented. Throttling starts with the more efficient dynamic voltage scaling policy and if not sufficient, the power monitor algorithm continues lowering the frequency. If an extreme cooling malfunction occurs, an Out of Spec notification will be initiated, requesting controlled shutdown. Lastly, the CPU can initiate a thermal shutdown and turn off the system."

I'd guess the thermal shutdown cannot be configured by software and would prevent any damage if the other mechanisms were either ineffective or somehow disabled by software.

Making schedulers runtime pluggable would make it really easy to get other people hacking on the Linux scheduler though.

For example, you could lash up a reusable test harness to allow scheduler testing under well defined and repeatable scenarios. This may then allow more direct comparison between schedulers hopefully leading to a best of breed race. Making it runtime un/loadable would also speed up the development cycle for the scheduler much in the same way that loadable modules can often be more rapidly debugged and fixed by not needing a reboot for each change.

You could even go crazy and make a scheduler plug in 'shim' just for the purpose of profiling different implementations under real workloads.

The only thing I would say is that the whole scheduler API should be made in such a way that the scheduler is undeniably covered by the GPL. Binary blob schedulers would be the worst possible outcome and would go against the thought of trying to open up the scheduler as a means of furthering development and healthy competition.

Lots and lots.

I find Java a lot of fun.

They probably worked out the costs if they sold >1M. They sold 100k, so never reached those economies of scale.

That's a shame, but at least they were thinking big. If they started out planning to sell 100k, they wouldn't have bothered.

I wish them luck in what they do next. Pleo is still unique.

> and of course, having a filesystem and a special MTD driver for
> *every single SSD drive manufactured* when they change flash
> chips or tweak the controller, could get unwieldy.

Large numbers of flash chips can be supported by the MTD CFI drivers:

http://en.wikipedia.org/wiki/Common_Flash_Memory_Interface

Something similar could be done for SSDs too, except they've chosen HDD standards as they are a better fit.

Mike