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".