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...
Last I heard the preferred language(s) for WinMo was
Would I be right in saying that this means you can calculate the amount of "spare" sectors a flash drive has for remapping (assuming the majority of cells are designed for remapping and very few for mapping tables).
Also, does this mean that as flash storage systems get bigger, they also get considerably more reliable, because they have, as a percentage, more remapping sectors? (4.9% for drives measured in MB, 7.4% for drives measured in GB). Since write speed doesn't scale linearly with size, it also means that even ignoring the different percentage of remapping sectors, the minimum lifespan still increases.
Also, for the same reason, presumably drive yields should increase since more cells can be faulty on the production line.
What about data barcodes or something. You don't get much data density, but at least it's digital.
You can be fairly certain it'll be readable, because all you need is a scanner or camera, and even if technology changes a lot, I can't imagine both of those disappearing too fast with nothing to replace them.
The challenge is decoding the data - formats and specifications come and go, but for someone determined enough, it's always possible to write some software to emulate an older system. Take jpeg for example - from the bare written specifications of jpeg, I think anyone reasonably competent at logic could re-implement from scratch all the code required to decode it and show it on a screen within a few weeks. (I even wrote a basic jpeg decoder myself, but it didn't output direct to a screen, and required an operating system to run under it for library functions like memory allocation and file access, so not entirely "from scratch")
Linux power management is generally poor due to poor drivers.
While the Linux drivers for most hardware devices are very stable due to their open source nature, many are reverse engineered from windows drivers or written from incomplete specs. Also, paid developer time is scarce for this kind of project, so often only core features get included.
The features which get cut are often power management and additional optimisation - the result, you end up with a system that doesn't perform great, and has poor battery life. Not much you can do about it without changing to different hardware.
I assume you're British, in which case you should know that over here pissed means a multitude of things, one of which means angry - clearly the intended meaning here.
Just because he's British doesn't mean he has to exclusively use the British alternative, my good sirs!
A little tidbit of information on the Chromium source code review site has revealed the primary processor for Chrome OS to run on will be an ARM Cortex A8 CPU, which raises some interesting questions about Googles aims for the product.
See more here:
http://www.omattos.com/node/9
A little tidbit of information on the Chromium source code review site has revealed the primary processor for Chrome OS to run on will be an ARM Cortex A8 CPU, which raises some interesting questions about Googles aims for the product.
See more here:
http://www.omattos.com/node/9
Having read through all those white papers about DirectAccess, to me it looks like just a new user interface and a re-branding of some functionality thats been in windows for a long time.
Effectively it's just creating some IPSec rules for the intranet subnet, and therefore every packet destined for the intranet gets encapsulated with an ESP header and sent onward - the Directaccess server simply decapsulates it. You can get the same functionality on Windows xp/2K3/Vista/2k8 by opening up the management console and adding the two IPSec snapins, and spending hours going through the hundreds of repetitive and recursive property pages to get it all set right.
One place this scheme will probably fail is if the company uses a private IP address range which is the same as the privcate IP address range the employee is currently connected to - in this case, the routing has to fail to connect to machines in one or other subnet - but thats the problem with nat...
Successful and fortunate crime is called virtue. - Seneca
