The idea of removing impurities using light is cool if it increases the efficiency of the completed pannel.

The premise of saving energy in the manufacture of the panels isn't really relevant. Currently producing silicon uses lots of energy, but it needen't really. The process really only involves heating and cooling of relatively small volumes of silicon, and if you were to design a machine to do it continuously, you could do it with nearly no energy. The raw materials are cold, the output is cold, and the processing in the middle is hot - use the energy from the finished product cooling down to heat new raw materials in a continuous process, as already done in a water Heat Exchanger.

The reason this currently isn't done is because energy is a tiny cost in the production of silicon, and other things are far more important than recapturing a tiny amount of energy while the silicon cools down.

While there is a small hacker subculture, and while they ever innovate and add features people want, the public (or at least some of them) will flock to the more open devices.

It isn't exactly something we can write laws about, because enforcement is hard, and it isn't something that is going to become law in every single country...

For my private reference use only: http://www.lime-exeter.co.uk/bat_paper.pdf

All other access unauthorized.

Plenty of good spacecraft suffer software malfunctions and fail as a result, and most failures end up with the craft not returning any data about what went wrong. Future crafts end up sent with exactly the same problems because we never find out about them.

There already exist plans for tiny satellites which can transmit a radio signal back to earth - eg. the Kicksat :http://www.kickstarter.com/projects/251588730/kicksat-your-personal-spacecraft-in-space

Why not glue lots of these Kicksats, self powered, to the outside of any spacecraft - maybe connect a few to internal data systems to collect more data. Now if the spacecraft blows up, if even a few survive the explosion, their radio signals can be tracked precisely by a reverse-gps scheme (where you triangulate exact position from many ground stations) allowing a realtime 3D model of the parts of the spacecraft which have kicksats on to be produced. Since some have connections to the internal monitoring systems, if only a few survive they can transmit data back to the ground very slowly over the next few days (very slowly since they have very limited transmission power)

It appears the problem only occurs with some chips, after some years, and where the issue occurs, it will only affect some of the SATA ports.

To me, it sounds like the best course of action from Intels point of view would to be to replace any failed chip when the user complains. The majority of users will never come across the issue, since most users won't have 3 or more SATA devices, and of those users that do, many will probably never get the problem, or if they do it'll be after the warranted period.

If I were Intel, I definitely wouldn't be recalling any chips that were already soldered onto a board without a direct user complaint. It might be fair enough to recall chips that aren't yet on a PCB, since then the cost is much lower, although even then I would just recall them, and then sell them again as slightly cheaper 2 port versions.

The refund procedure could be entirely Intel handled where all returned boards get dumped directly into "recycling", and the user sent a check for $100 (or more if they include a receipt for the board).

Since this ISN'T what Intel is doing, it makes me suspect there is something else more serious wrong with them...

CPU power and ease of design is the main thing. JPEG is specially designed to allow encoding and decoding with very little memory bandwidth, at the expense of compression ratio.

The reason is because JPEG can be encoded in 16x16 pixel blocks. No block depends on any other block, which allows encoders to only worry about a tiny part of the image at once. This allows each part of the uncompressed image to be read from RAM exactly once, and temporary intermediate "state" data is a fixed size which isn't proportional to the image size, which makes hardware design easy. Also, since there is independence between blocks, hardware encoders can be made which process many parts of an image simultaneously - thats how a cheap camera can compress a multi-megapixel image to jpeg in a fraction of a second.

The disadvantage of this is if all the 16x16 blocks in an area are very similar (for example a repeating pattern), the encoder can't know this, so there is minimal compression advantage. (I say minimal because another stage of jpeg compresson, the coefficient huffman tree might possibly help in some rare cases)

WebP on the other hand I expect chucks this idea out of the window in favour of compression ratio, but at the same time is also chucking out of the window the possibility of fast cheap simple hardware encoders and decoders.

Note that single-core software encoders probably aren't affected as much by this, and today most image decoding is single threaded and software based, so the impact may not be as large as I made out.

Using trampolines for every cross-library call seems very inefficient...

The windows method seems better for the more common case, where it does the costly rewriting at library load time, and then avoids an extra jump for every library function call.

Whats the performance impact of this? I bet it's at least a couple of percent, which is significant if it's across the entire system.

Yes, we should penalize them.

Imagine there are two sites with the information I need. I would much prefer to see the faster site than the slower one, because by loading the faster site I get my information faster.

If I wanted my information slowly, I would walk to the library...

Anyone feel like replicating this experiment with a standard flash chip scrounged from a USB stick?

It would also be nice to try an entirely software approach on a USB stick plugged into a pc, to see how good the wear levelling in commodity usb sticks is.

After each of the above suggestions, remember to reboot your router, since it won't speed adjust without a reboot.

Also, check the speed according to the router configuration page. If you get a higher speed showing there, you'll see a real speed increase after a few days when all the systems in BT's network re-adjust to the new speed (see "BRAS profile" on google for details)

I don't understand why all mobile makers are so touchy about turn-by-turn navigation.

When you've paid for the map data, and got GPS hardware in your device, it seems crazy not to implement turn by turn navigation, since the added software development cost is pretty minimal.

I suspect the problem is more of a licensing one - for example, when turn by turn navigation came out for android, it was US only for a while. A hack existed to enable it in the rest of the world, but that was soon stopped by google. Only later did it get released for the rest of the world.

Considering that it worked with a hack, it can't have been a softwatre issue that was preventing worldwide release - the only possibility is that licensing and company politics was getting in the way. Maybe people like tomtom get exclusive rights to do navigation on map data, and therefore while google has rights to use the maps, they don't have rights to do turn by turn directions with them?

I'm pretty sure the surface temperature of the skin on my fingers sometimes falls below 15 Celsius if I've just come in from the snow outside or something. Also, I know that in hot countries ambient temperature of a usb stick could easily reach 30 Celsius.

Knowing these two facts, it seems there is no threshold they could use to accurately detect if a finger is "attached" or not...

I don't see the advantage of full wave rectification, except possibly to meet power regulations. A pulsed LED actually appears brighter to the human eye, and provided the average power through it is the same as a full wave rectified model then the brightness should be the same*. The only real reasons for going full wave rectified and smoothed is either where power regulations specify certain restrictions on power harmonics (imagine if every device was half wave rectified in the world, then the power supply would be loaded at some points in the cycle more than others, and you would no longer get a nice clean sine wave), or where you want a constant voltage to make design of the rest of the circuit easier (eg. digital electronics).
.

* LED's can be an exception to this in certain cases, since the number of photons produced per second is not linear to the instantaneous current.

The export tools they use are never going to export ALL the data - for example, my email program keeps track of my recently used contacts and puts them at the top of the list. If I were to export my contact list and re-import into another app, the order of the list would be reset.

In a similar way, if I export all my email from one mail service to another, I might loose any labels or flags\stars I had put on the messages, even if my new service supported labels/stars/flags, simply because the export format, being generic, doesn't contain that data.

This is just so they can get the infrastructure in place for per-play or per-minute music charging. It would be trivial to hook this server up to the phone companies billing system to bill users every time they played a song.

The next step is then to provide addons to contracts offering "unlimited" songs, for only an additional $15 per month...