The minimum cost on ARM-based processors is somewhere around the $2 mark. I can get PICs for down to about $0.30. There's plenty of products where that sort of difference is significant - and easily high enough volume to drown any development time cost difference.
It's a policy thing. A lot of routers are configured not to accept announcements for smaller than a/24 - too many of those routes eat a lot of RAM. The protocols all support all prefix lengths, but that's not to say that people will actually permit them on real networks - especially the big core routers.
Within any one memory device the timings would still be constant, though - a single CPU can access all the data within any one device in constant time across that device.
That constant will be faster for local memory than for another CPU's RAM, but within any one RAM device it's still constant.
Actually, no, it's exactly the functionally descriptive term I'm challenging.
The normal definition is a memory with flat access times - i.e. it doesn't matter what part of the memory you access, you can do it equally quickly. This doesn't apply for things like tapes or HDDs, which are respectively either sequential or semi-sequential (sequential per cylinder) access.
In the case of flash the time to perform a write is strongly dependent on the preexisting erase state of the block - if it's cleared already, it's much faster than if you need to clear it. That means that the time to access a given block of memory isn't constant (or even nearly so) so it's not really random-access.
(If you want to be really nit-picky, it's random access on reads but not on writes. It can even end up being more complicated since you can have a read queued behind a erase on some flash devices)
Actually, no it's not. Flash can't be written to randomly; it needs a block erase cycle first (and generally a block is fairly large; we're not talking one or two bytes here). Technically you can zero bits without an erase, but not set them to 1 (erasing sets everything to 1).
This is why there's a distinction between EEPROM, FLASH, and RAM.
It's not just the firewall protecting them here. Both group policy prevents that in the first place, plus the script won't connect successfully with the firewall in the way. That's tested against both 64 and 32 bit Windows 7 installs done from the RTM build, by the way.
Having actually tried this on three windows 7 machines now, it doesn't seem to work on every machine. (Actually, it's yet to work on any here, although I hear tell that it does work on some). There's something more to this than just "that data crashes it every time".
There's no such thing as "properly scaling" between 720 and 766/768 (I think the hardware resolution's 766 not 768 if I remember right; either way, 2 pixels don't matter - the video mode on the PC is certainly 768 though). They're far too close together to scale without beat frequency issues. Not accepting the native resolution I'd agree is a definite failing of the product, but I honestly can't criticize the scaler - it does as good a job as can reasonably be expected i.e. bloody awful. At the end of the day, to scale between these resolutions means inserting 48 extra lines into the display *somewhere*. It doesn't matter how nicely you do this, or how intelligent the algorithm, it's still going to mess up display of text or any fine-detailed horizontal pattern.
The inability to set the native resolution I suspect may be part of some misguided effort to avoid confusing anything connected to it - at least it's safe to tell games consoles etc. that it does 720p and 1080p; I assume they'd ignore an extra 768 resolution, but I wouldn't be too amazed if that messed something up on some product somewhere.
Actually, that setting performs DREADFULLY. 1280x720 gets scaled to 766 high, giving nasty moire patterns on any horizontal lines and generally messing things up. Getting it to scale 1366x768 (that it thinks is part of a 1920x1080) produces a good 1:1 mapping with no artifacts. The scaler might scale video from 1280x720 nicely, it certainly doesn't work for text or anything with fine detail (e.g. games). It's a pretty strange behaviour, but it works. This isn't actually a screwup, as such, on the part of the TV - it supports 720p and 1080p, and nothing else. If you give it an intermediate resolution it picks one or other (which isn't entirely unreasonable since it's a TV not a monitor) but the zoom/aspect ratio function behaves itself nicely and can extract the middle section at native resolution if you want.
Interestingly, these TVs appear to run linux! (it's mentioned in the "about this product" information in the menus.)
Unfortunately it's not always as simple as this. My panasonic TV only allows two resolutions on the HDMI port - 1080p or 720p. But the hardware resolution's 766, so the right way to get a 1:1 mapping of pixels on the PC is as follows: Configure PC to 1366x768. This would be the right resolution, but the TV won't actually accept that resolution. Set the PC NOT to scale to output panel size. This gives a 1366x768 patch in the middle of a theoretically 1080p res screen. Configure the TV's scaling to stretch that patch to full screen (Zoom 2 if you're using a panasonic viera TV)
A lot of people seem to have missed that the Sony PRS-500 runs Linux. Sure, the application on it is proprietary, but the system itself isn't excessively locked down and it's fairly easy to tweak.
Don't bash Sony too hard on this one; it's actually a nice device.
Interestingly the Nokia N800, also being recommended by many people above, runs linux too.
Nokia actually have a product that's intended to do pretty much what you suggest, called Sensor. However, it's nokia-specific and as far as I know the protocol's proprietary, and it's supported on a fairly small set of devices.
There's also been a recent port of Apache to the Nokia Series 60 devices, which would potentially allow something similar to be DIY'd up nicely.
You don't need stateful packet inspection to tell you that source address & port == destination address & port - land isn't a particularly subtle attack.:-)
Some of the "unlockable features" of the 300D are actually rather handy; for example, the maximum sensitivity of the sensor can be changed from ISO 1600 to 3200, the auto-focus modes can be selected (not from the 10D's full range, but it's still nice to have it in one-shot mode and know the camera won't go off on a focus hunt half-way through framing a shot), the ability to set flash exposure compensation, and the ability to fix the shutter speed in aperture-priority mode are all rather useful features.
A more open camera would allow various other features that have sadly vanished from modern cameras; time-lapse features spring to mind, as do things like selectable metering areas.
Obviously, Canon rather like these features to remain absent in the 300D as it provides a reason to buy the more expensive models, even for those who don't particularly need full-frame sensors, waterproofing or magnesium alloy bodies. There's also the matter of auto-focus algorithms, which are one of the areas of significant difference between camera manufacturers - presumably Canon would be less than impressed to find their code copied in a Nikon or Minolta.:)
Slashdot Mirror
Sure, but for businesses, that relies on a very precarious licensing situation, and is basically unsupportable.
Basically you're not thinking small enough.
The minimum cost on ARM-based processors is somewhere around the $2 mark. I can get PICs for down to about $0.30. There's plenty of products where that sort of difference is significant - and easily high enough volume to drown any development time cost difference.
You mean some way, like, say, swapping SIM cards as is commonplace in europe, or on any of the GSM networks in the states, for that matter?
It's a policy thing. A lot of routers are configured not to accept announcements for smaller than a /24 - too many of those routes eat a lot of RAM. The protocols all support all prefix lengths, but that's not to say that people will actually permit them on real networks - especially the big core routers.
Within any one memory device the timings would still be constant, though - a single CPU can access all the data within any one device in constant time across that device.
That constant will be faster for local memory than for another CPU's RAM, but within any one RAM device it's still constant.
Actually, no, it's exactly the functionally descriptive term I'm challenging.
The normal definition is a memory with flat access times - i.e. it doesn't matter what part of the memory you access, you can do it equally quickly. This doesn't apply for things like tapes or HDDs, which are respectively either sequential or semi-sequential (sequential per cylinder) access.
In the case of flash the time to perform a write is strongly dependent on the preexisting erase state of the block - if it's cleared already, it's much faster than if you need to clear it. That means that the time to access a given block of memory isn't constant (or even nearly so) so it's not really random-access.
(If you want to be really nit-picky, it's random access on reads but not on writes. It can even end up being more complicated since you can have a read queued behind a erase on some flash devices)
Actually, no it's not. Flash can't be written to randomly; it needs a block erase cycle first (and generally a block is fairly large; we're not talking one or two bytes here). Technically you can zero bits without an erase, but not set them to 1 (erasing sets everything to 1).
This is why there's a distinction between EEPROM, FLASH, and RAM.
All three are my own actually - one of the perks of SA roles, you get machines to play with. :)
It's not just the firewall protecting them here. Both group policy prevents that in the first place, plus the script won't connect successfully with the firewall in the way. That's tested against both 64 and 32 bit Windows 7 installs done from the RTM build, by the way.
Having actually tried this on three windows 7 machines now, it doesn't seem to work on every machine. (Actually, it's yet to work on any here, although I hear tell that it does work on some). There's something more to this than just "that data crashes it every time".
There's no such thing as "properly scaling" between 720 and 766/768 (I think the hardware resolution's 766 not 768 if I remember right; either way, 2 pixels don't matter - the video mode on the PC is certainly 768 though). They're far too close together to scale without beat frequency issues. Not accepting the native resolution I'd agree is a definite failing of the product, but I honestly can't criticize the scaler - it does as good a job as can reasonably be expected i.e. bloody awful. At the end of the day, to scale between these resolutions means inserting 48 extra lines into the display *somewhere*. It doesn't matter how nicely you do this, or how intelligent the algorithm, it's still going to mess up display of text or any fine-detailed horizontal pattern.
The inability to set the native resolution I suspect may be part of some misguided effort to avoid confusing anything connected to it - at least it's safe to tell games consoles etc. that it does 720p and 1080p; I assume they'd ignore an extra 768 resolution, but I wouldn't be too amazed if that messed something up on some product somewhere.
Interestingly, these TVs appear to run linux! (it's mentioned in the "about this product" information in the menus.)
Unfortunately it's not always as simple as this. My panasonic TV only allows two resolutions on the HDMI port - 1080p or 720p. But the hardware resolution's 766, so the right way to get a 1:1 mapping of pixels on the PC is as follows:
Configure PC to 1366x768. This would be the right resolution, but the TV won't actually accept that resolution.
Set the PC NOT to scale to output panel size. This gives a 1366x768 patch in the middle of a theoretically 1080p res screen.
Configure the TV's scaling to stretch that patch to full screen (Zoom 2 if you're using a panasonic viera TV)
A lot of people seem to have missed that the Sony PRS-500 runs Linux. Sure, the application on it is proprietary, but the system itself isn't excessively locked down and it's fairly easy to tweak.
Don't bash Sony too hard on this one; it's actually a nice device.
Interestingly the Nokia N800, also being recommended by many people above, runs linux too.
Nokia actually have a product that's intended to do pretty much what you suggest, called Sensor. However, it's nokia-specific and as far as I know the protocol's proprietary, and it's supported on a fairly small set of devices. There's also been a recent port of Apache to the Nokia Series 60 devices, which would potentially allow something similar to be DIY'd up nicely.
You don't need stateful packet inspection to tell you that source address & port == destination address & port - land isn't a particularly subtle attack. :-)
Some of the "unlockable features" of the 300D are actually rather handy; for example, the maximum sensitivity of the sensor can be changed from ISO 1600 to 3200, the auto-focus modes can be selected (not from the 10D's full range, but it's still nice to have it in one-shot mode and know the camera won't go off on a focus hunt half-way through framing a shot), the ability to set flash exposure compensation, and the ability to fix the shutter speed in aperture-priority mode are all rather useful features.
:)
A more open camera would allow various other features that have sadly vanished from modern cameras; time-lapse features spring to mind, as do things like selectable metering areas.
Obviously, Canon rather like these features to remain absent in the 300D as it provides a reason to buy the more expensive models, even for those who don't particularly need full-frame sensors, waterproofing or magnesium alloy bodies. There's also the matter of auto-focus algorithms, which are one of the areas of significant difference between camera manufacturers - presumably Canon would be less than impressed to find their code copied in a Nikon or Minolta.