If your monitor and VGA card aren't completely braindead, these days, X, if properly configured to do so, will use DDC to extract your monitor's make, model and claimed EDID specifications automagically, and use that to pick an optimum resolution. If your monitor lies about its specification, or can't do DDC (hint: my 15" Iiyama CRT from 1995 can), then you're out of luck. If your distro doesn't configure X to use DDC, again, you're out of luck.
Support for security patches and feature upgrades will end April 2009.
No, as explained by Microsoft's XP lifecycle page read in conjunction with their lifecycle definitions, Extended Support (presently available until 8 April 2014) includes: Paid support and Security update support at no additional cost but Non-security related hotfix support requires a separate Extended Hotfix Support Agreement to be purchased (per-fix fees also apply).
But you have to admit, Microsoft helped bring computing to the masses. If there had been no Microsoft, the internet would be what USENET was back in the day: something used by geeks and scientists and not much else. In that sense, I think he's right.
I think that's what Mundie is getting at, but I don't think his conclusion is correct; Mosaic (i.e. a GUI web browser) was around in 1993, and TCP/IP stacks were available on non-server platforms (e.g. AmiTCP on the Amiga) became available at the same time. So it wasn't required for Microsoft and their platform to be successful, only for someone (or many someones) to make TCP/IP devices available and usable by non-geeks.
If it hadn't been for Microsoft, I'm sure someone else would have done it - most likely Nokia or one of the other cellphone manufacturers (as they eventually did). In fact, I think that long-term, IP-enabled cellphones will be the most prolific platform for non-professional IT users (and many professional IT users too!) and eventually eclipse Microsoft's achievements with Windows.
I can't think of any good reason to use TOR from an embassy unless you are keeping secrets from your own country. In which case, maybe you ought to consider not committing treason.
How about OSINT without letting your target know what you're taking an interest in?
Still, dumb to leave it enabled all the time (or even have it configured on your 'normal' machine), unless it's an active disinformation programme!
Why would we care if GPLed software isn't used in embedded devices? If the full source for the software shipped in the device isn't available, it might as well be BSD- or proprietarily licensed for practical purposes anyway.
Presumably, there might be some Linux fanboys out there who buy a device primarily because 'it runs Linux', but I think most people buy a device based on how useful it is (which may or may not be related to it running Linux!). This even applies to hackers, who'll buy a device based on how open it is, or how functional the hardware is compared with its price.
SuperFetch. Possibly even somewhat useful, if your usage of your computer follows a fairly similar schedule each day (e.g. start Thunderbird, Firefox and IM at 9am, start Solitaire at 12pm, start Word at 1pm).
In bit rot, bits on HDD spontaneously change. It is generally not observable and the results are often blamed on applications and/or OS.
It is lesser known because in the current state of technology, the aplications, OS, filesystem and even RAID can't even detect the problem much less solve them. (RAID doesn't work because it can't tell which copy is right and which is wrong. It assumed what it got from disk is what it wrote to it.)
Sure RAID can, in most circumstances; blocks are protected with checksums and/or ECC, and a single bit flip is likely to be detected and corrected by the drive, or else the drive will throw a read error in response to the IO request. With appropriate handling in the RAID software or hardware layer, the block can be read instead from the other drive(s) in the array. The RAID software or hardware should then attempt a refresh write of the block that failed. If this fails, the drive should be failed out and replaced, but if it was a soft error, or a hard error on a block that is able to be remapped by the drive, then everything's good.
I've been thinking along the same lines myself for a number of years now, but my take was that IP laws should define a formula for calculating the protection term for the categories of IP that they protect based on, say, the median number of protectable works per capita.
a) Presumably recent versions of Windows include equivalent functionality to Tigran Aivazian's microcode_ctl for Linux, which allows the CPU microcode to be updated from firmware files once the OS has booted. (The usual way is that the BIOS ships with a set of updated microcode firmwares for various supported CPUs and loads them during the pre-boot phase of startup).
b) If you're running a Red Hat-derived distro, watch out for updates to the kernel-utils package, which provides microcode_ctl and/etc/firmware/microcode.dat. It might also be worth checking Tigran's site a bit more regularly. I note that his page includes a microcode.dat which is about 7 months newer than that currently provided by CentOS 4.5's kernel-utils package.
The FDIV bug and associated fallout shortly preceded Intel's introduction of the microcode update facility. I don't think the two issues are unrelated.
I don't know about the Intel side of things, but over on the AMD side of things, I wouldn't buy a Gigabyte or Asus board. For some reason, they have a good reputation for quality, but my experience is that they are junk with high failure rates.
I heard this from the local mom and pop PC shop when I was shopping around for my last set of boards, but decided to trust my experience (i430HX and i810 Gigabyte boards for a friend, an i440BX Asus board myself) and, sure enough, it all worked out with the two i845PE Gigabyte boards I bought. In the meantime, I've experienced problems getting ATA working sufficiently well to drive a 4x CD writer on an AMD K6-2/VIA machine.
The thing to remember is that Asus and Gigabyte sell a lot of boards, and so problems will tend to be broadcast far and wide. Successes don't tend to get broadcast to the same extent! On the other hand, there is always the temptation for 'top dogs' to become complacent, and 'second tier' vendors will often try hard as they have something to prove in order to try and achieve their aspirations of one day becoming 'first tier' themselves ('third tier' vendors simply don't care, I think - they sell crap, and they know it, but that's their place in the world. If they aspire to sell better kit, they'll create a new brand to do so, with mixed results).
It's a shame that everyone in this sub-thread seems to be recommending nVidia chipsets for AMD processors. Until that changes, I won't be buying an AMD system, which is a shame, as they've been putting out quite elegant and cost-effective designs.
By the way, though I agree with you in general, as many fans as possible is not always a good idea. It makes a lot of difference where they are placed, and the thing you do not want to do is to create internal vortices.
True; I was being a bit flippant. I aim to bring in cool at the front and bottom of a tower case, and exhaust warm air from the top of the back, hopefully resulting in forced convection to do as good a job as can be done without a thermal lab.
"Quality motherboards" is the tricky bit in your post...
I'm using an Asus motherboard (P5ND2-SLI) and the number of problems I've had is unbelievable.
Personally, I disqualify nVidia chipsets immediately, primarily due to the necessity to use their proprietary drivers, but secondarily because I've never had a problem with Intel chipsets supporting Intel CPUs, whereas I have had problems with AMD on SiS and VIA and Intel on UMC.
Firstly the power supply controller on the motherboard is faulty, so I have to short the power on pin on the ATX connector to ground with a paper clip to get any action at all.
Why didn't you return it immediately for a refund? Behaviour like that strikes me as a clue that the design 'ain't right, or it isn't compatible with the PSU you've chosen
Then the Asus drivers totally screwed my Windows XP SP2 installation over, BSODs, freezing, no booting.
See above re. nVidia drivers. Nice to see that even their Windows drivers are problematic for some. Not.
Reinstall needed...
Then I had to upgrade the BIOS to change the CPU fan speed...
I couldn't get the onboard LAN to work at all with Slackware 11, but Slackware 12 worked OK (but this is probably my fault not theirs...).
...nVidia drivers...
Motherboard manufacturers don't see reliability and stability as major goals, cutting expenses, faster production rates and quick improvements to their products make them more money.
Some do, some don't. And of the ones that do, they have products targeted at serious users and others for gamers. Don't confuse their product lines.
Additionally, I daresay that they bank on the fact that most people who buy a computer/motherboard will replace it before various bits start to fail...
That's cyclic; I used to buy the best motherboard I could, and the cheapest CPU that would fit, in expectation of upgrading the CPU every year or so as prices fell. These days, increasingly, you seem to need a new chipset and memory to get the best from later CPUs, so I'd not place quite so much emphasis on claimed future upgradeability as it probably won't pan out (the last boards I bought had 18x multipliers and 667MHz FSB; Intel jumped from 533MHz FSB to 800MHz, and didn't go higher than 3.2GHz).
Now what I would like to see advertised - but won't - is slower but highly reliable motherboards, processors and memory at commercial prices. How about a Core Duo Reliability Edition? I would reallyt like to be able to build a server and a few desktops from commodity hardware and almost be able to forget about them for 5 years.
Er, that's exactly why I stick with Intel CPUs on quality motherboards (Gigabyte/ASUS) that use Intel chipsets and Crucial memory, despite the taunting of my AMD fanboy friends. Also, pay attention to your cooling and PSU (i.e. fit as many fans as you physically can fit in the case, and don't use the cheapest case/PSU combination you can find), as cutting corners here will severely impact your reliability. I'm not interested in overclocking, either. My oldest self-built Intel machine is 9 years old this summer and being used as a desktop by my dad. I also have a 5 year old Celeron machine that's on 24/7 as my MythTV box and firewall.
I know it's possible to build reliable AMD-based systems, but it seems to be harder work, and probably involves going with an Opteron on a Tyan or Supermicro board in order to be able to use an AMD chipset, rather than one of the third-party (e.g. VIA, SiS, ALI) chipsets.
Electrolytic capacitor reliability has been a problem throughout the electronics industry for the last 10 years or so, but even that should be less of a problem shortly. Gigabyte, for one, are introducing all-solid capacitor boards to eliminate this weak link in the chain.
Sorry for the naive question in advance, but I was under the impression that some flavors of BSD (OpenBSD?) were extremely secure as well. Is that not so? In that case, wouldn't a BSD version be more suitable for secure/sensitive installations?
No, because without the certification, secure/sensitive installations aren't allowed to use those flavours of BSD (or any other uncertified product). If there's no other way of performing a function, it might be justifiable, but it'll be a brave sysadmin that pursues such a course.
The above has no bearing on BSD's relative technical merits and demerits compared with OSs that have achieved CC certification.
In answer to your questions, a RAID5 array will be limited to (n-1)*max(sizeof(d1),sizeof(d2)...)), where n is the number of array members, and the sizeof(dx) figures are determined at creation time of the array. If you're using Linux software RAID, and you don't use the raw devices (e.g./dev/hda,/dev/hdb) as array members, but partitions instead (e.g./dev/hda1,/dev/hdc5), then you can of course partition the unused space in some way and use that how you wish. I'd strongly caution against putting two or more array members on the same physical disc, though, as if the device dies, it'll take out those array members probably causing the entire array to become inaccessible!
I don't like Linux's software RAID implementation, as it immediately drops member devices out of their array in the event of a read error. I gather at least one implementation of software RAID in at least one flavour of BSD will immediately try to refresh the blocks that generated the read error using data from the other array members. This is the correct approach, IMNSHO, since doing it the Linux way means that if another array member encounters a read error whilst re-building the array, you lose the entire array.
If you're going to use JBOD, you probably might as well use RAID 0 and get better performance. The reliability will be lower than a single drive though (1/n, in fact).
RAID10 (stripes over mirrors) is the Rolls-Royce solution. It can tolerate upto (n/2) drives failing, and degraded performance is better than RAID 0+1, and array rebuilds are quicker than RAID 0+1 too. It doesn't come cheap, though, since you need at least 4 discs and you only get n*2 capacity.
It really depends on how important it is to maintain your media data; I have backups of the MP3s I've ripped (in addition to the original CDs) and my TV recordings are disposable, so I use a single 300GB disc in my MythTV box. I'm thinking of upgrading this to 2 * 500GB and putting TV recordings on one, and everything else on the other.
Unless you have the air conditioner on, any household appliance is 100% efficient, since the 'waste' heat goes towards heating your house.
Only if your normal household heating is electrical. If you normally heat your home with gas, for example, you'll find that it's about 4 times cheaper per kWh than electricity. This makes sense if you consider the losses involved in generating the electricity from other sources of energy (e.g. gas), transmission losses and profit/convenience premium.
Actually, disk drives (both 5.25" and then-newfangled 3.5") were available for the Spectrum. Just not from Sinclair.
Which is probably why virtually no commercial games were available on floppy disk for the system.
OTOH, this did result in a wide array of "red button" gadgets (e.g. Romantic Robot's "Multiface") that used the NMI to stop the application/game whilst it was running, save its register state, overlay its ROM over the standard system ROM and jump into it. The system ROM usually included options for dumping the current state to microdrive or floppy, as well as various hacking/disassembly options. Later disk controllers (e.g. MGT's DISCiPLE and Plus D) started including such devices as standard.
Eventually, these NMI gadgets spread to other platforms, such as the Commodore 64 and Amstrad CPC, but I think it's fair to say they originated with the Spectrum due to the need for their existence on that platform.
Or people who weren't loaded with money. You were obviously one of those spoilt little gits. **** off back to your rich parents.
No, I didn't have a Spectrum, let alone a 16K model; but in the early days there was a major price difference, and one has to remember that the £175 for the 48K model would translate to almost £400 in today's money. The 16K model was "only" £125.
I can confirm this; as a 9 1/2 year old, at £99.99, my 16K Spectrum was only possible by grouping my parents' Christmas present with that of my grandparents. A friend got a 48K model at the same time by it being a shared present between him and his older brother. I planned to get a 32K upgrade to 48K a few months later as my birthday present, if I was still using it (I was, and continued to do so until June 1990 when I got my Amiga 500!). As it happened, around that time, the glue holding the metal keyboard to the plastic case gave way and we returned it under warranty. By then, the retailer only had 48K models for £129.99 and would exchange if we paid the £30 difference.
According to this inflation calculator, £175 in 1982 was worth between £413 (based on RPI) and £773 (based on GDP) in 2005 (the figure based upon average earnings is about halfway between those numbers), £125 was between £295 and £552. In 1983, £129.99 was between £293-£525 and £99.99 was between £226-£404. For the C64 and BBC B fans out there, their 1983 price (without any accessories, like C2N, 1541, RGB monitor) of £399 was £901-£1612 in 2005 prices.
That certainly reportedly happened in the Spectrum days too; 4164 64Kbit*1 DRAM ICs were constructed as two 32Kbit*1 cells internally. The manufacturer realized that these cells could be individually tested and the resulting ICs marketed as 4132 32Kbit*1 ICs, marked H or L according to whether high or the low half was functioning (which was why you needed a matching set of 8 in Spectrum RAM upgrade kits). The Spectrum's memory consisted of 8 4116 16Kbit*1 ICs for the lower 16KByte of memory (which was slower as CPU access was contended with the ULA as that's where the framebuffer lived), from 0x4000 to 0x7fff and 8 4132 32Kbit*1 ICs for 0x8000 to 0xffff. Eventually, the yields on 4164s rose and the supply of 4132s dried up, so fully-functioning 4164s were used for the upper 32KByte - as seen in my own vintage Spectrum (though the extra 32KByte was inaccesible without custom bank-switching circuitry).
Slashdot Mirror
I loved that page zero thing. Very, very fast. One could do things in a 1 MHz 6502 people wouldn't touch in a 4 MHz Z-80...
On the other hand, use Z80'ers had single instructions for block data copy (LDIR) and similar instructions for IO IN/OUT (OTIR/OTDR/INDR/INIR).
If your monitor and VGA card aren't completely braindead, these days, X, if properly configured to do so, will use DDC to extract your monitor's make, model and claimed EDID specifications automagically, and use that to pick an optimum resolution. If your monitor lies about its specification, or can't do DDC (hint: my 15" Iiyama CRT from 1995 can), then you're out of luck. If your distro doesn't configure X to use DDC, again, you're out of luck.
No, as explained by Microsoft's XP lifecycle page read in conjunction with their lifecycle definitions, Extended Support (presently available until 8 April 2014) includes: Paid support and Security update support at no additional cost but Non-security related hotfix support requires a separate Extended Hotfix Support Agreement to be purchased (per-fix fees also apply).
I think that's what Mundie is getting at, but I don't think his conclusion is correct; Mosaic (i.e. a GUI web browser) was around in 1993, and TCP/IP stacks were available on non-server platforms (e.g. AmiTCP on the Amiga) became available at the same time. So it wasn't required for Microsoft and their platform to be successful, only for someone (or many someones) to make TCP/IP devices available and usable by non-geeks.
If it hadn't been for Microsoft, I'm sure someone else would have done it - most likely Nokia or one of the other cellphone manufacturers (as they eventually did). In fact, I think that long-term, IP-enabled cellphones will be the most prolific platform for non-professional IT users (and many professional IT users too!) and eventually eclipse Microsoft's achievements with Windows.
I can't think of any good reason to use TOR from an embassy unless you are keeping secrets from your own country. In which case, maybe you ought to consider not committing treason. How about OSINT without letting your target know what you're taking an interest in? Still, dumb to leave it enabled all the time (or even have it configured on your 'normal' machine), unless it's an active disinformation programme!
Presumably, there might be some Linux fanboys out there who buy a device primarily because 'it runs Linux', but I think most people buy a device based on how useful it is (which may or may not be related to it running Linux!). This even applies to hackers, who'll buy a device based on how open it is, or how functional the hardware is compared with its price.
...and I'm not the only person who thinks so, either
SuperFetch. Possibly even somewhat useful, if your usage of your computer follows a fairly similar schedule each day (e.g. start Thunderbird, Firefox and IM at 9am, start Solitaire at 12pm, start Word at 1pm).
It is lesser known because in the current state of technology, the aplications, OS, filesystem and even RAID can't even detect the problem much less solve them. (RAID doesn't work because it can't tell which copy is right and which is wrong. It assumed what it got from disk is what it wrote to it.)
Sure RAID can, in most circumstances; blocks are protected with checksums and/or ECC, and a single bit flip is likely to be detected and corrected by the drive, or else the drive will throw a read error in response to the IO request. With appropriate handling in the RAID software or hardware layer, the block can be read instead from the other drive(s) in the array. The RAID software or hardware should then attempt a refresh write of the block that failed. If this fails, the drive should be failed out and replaced, but if it was a soft error, or a hard error on a block that is able to be remapped by the drive, then everything's good.
I've been thinking along the same lines myself for a number of years now, but my take was that IP laws should define a formula for calculating the protection term for the categories of IP that they protect based on, say, the median number of protectable works per capita.
Ah, I wasn't sure Intel ever made the link public and explicit.
No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves using the CPUID opcode.
b) If you're running a Red Hat-derived distro, watch out for updates to the kernel-utils package, which provides microcode_ctl and /etc/firmware/microcode.dat. It might also be worth checking Tigran's site a bit more regularly. I note that his page includes a microcode.dat which is about 7 months newer than that currently provided by CentOS 4.5's kernel-utils package.
The FDIV bug and associated fallout shortly preceded Intel's introduction of the microcode update facility. I don't think the two issues are unrelated.
I heard this from the local mom and pop PC shop when I was shopping around for my last set of boards, but decided to trust my experience (i430HX and i810 Gigabyte boards for a friend, an i440BX Asus board myself) and, sure enough, it all worked out with the two i845PE Gigabyte boards I bought. In the meantime, I've experienced problems getting ATA working sufficiently well to drive a 4x CD writer on an AMD K6-2/VIA machine.
The thing to remember is that Asus and Gigabyte sell a lot of boards, and so problems will tend to be broadcast far and wide. Successes don't tend to get broadcast to the same extent! On the other hand, there is always the temptation for 'top dogs' to become complacent, and 'second tier' vendors will often try hard as they have something to prove in order to try and achieve their aspirations of one day becoming 'first tier' themselves ('third tier' vendors simply don't care, I think - they sell crap, and they know it, but that's their place in the world. If they aspire to sell better kit, they'll create a new brand to do so, with mixed results).
It's a shame that everyone in this sub-thread seems to be recommending nVidia chipsets for AMD processors. Until that changes, I won't be buying an AMD system, which is a shame, as they've been putting out quite elegant and cost-effective designs.
True; I was being a bit flippant. I aim to bring in cool at the front and bottom of a tower case, and exhaust warm air from the top of the back, hopefully resulting in forced convection to do as good a job as can be done without a thermal lab.
I'm using an Asus motherboard (P5ND2-SLI) and the number of problems I've had is unbelievable.
Personally, I disqualify nVidia chipsets immediately, primarily due to the necessity to use their proprietary drivers, but secondarily because I've never had a problem with Intel chipsets supporting Intel CPUs, whereas I have had problems with AMD on SiS and VIA and Intel on UMC.
Firstly the power supply controller on the motherboard is faulty, so I have to short the power on pin on the ATX connector to ground with a paper clip to get any action at all.
Why didn't you return it immediately for a refund? Behaviour like that strikes me as a clue that the design 'ain't right, or it isn't compatible with the PSU you've chosen
Then the Asus drivers totally screwed my Windows XP SP2 installation over, BSODs, freezing, no booting.
See above re. nVidia drivers. Nice to see that even their Windows drivers are problematic for some. Not.
Reinstall needed... Then I had to upgrade the BIOS to change the CPU fan speed... I couldn't get the onboard LAN to work at all with Slackware 11, but Slackware 12 worked OK (but this is probably my fault not theirs...).
Motherboard manufacturers don't see reliability and stability as major goals, cutting expenses, faster production rates and quick improvements to their products make them more money.
Some do, some don't. And of the ones that do, they have products targeted at serious users and others for gamers. Don't confuse their product lines.
Additionally, I daresay that they bank on the fact that most people who buy a computer/motherboard will replace it before various bits start to fail...
That's cyclic; I used to buy the best motherboard I could, and the cheapest CPU that would fit, in expectation of upgrading the CPU every year or so as prices fell. These days, increasingly, you seem to need a new chipset and memory to get the best from later CPUs, so I'd not place quite so much emphasis on claimed future upgradeability as it probably won't pan out (the last boards I bought had 18x multipliers and 667MHz FSB; Intel jumped from 533MHz FSB to 800MHz, and didn't go higher than 3.2GHz).
Er, that's exactly why I stick with Intel CPUs on quality motherboards (Gigabyte/ASUS) that use Intel chipsets and Crucial memory, despite the taunting of my AMD fanboy friends. Also, pay attention to your cooling and PSU (i.e. fit as many fans as you physically can fit in the case, and don't use the cheapest case/PSU combination you can find), as cutting corners here will severely impact your reliability. I'm not interested in overclocking, either. My oldest self-built Intel machine is 9 years old this summer and being used as a desktop by my dad. I also have a 5 year old Celeron machine that's on 24/7 as my MythTV box and firewall.
I know it's possible to build reliable AMD-based systems, but it seems to be harder work, and probably involves going with an Opteron on a Tyan or Supermicro board in order to be able to use an AMD chipset, rather than one of the third-party (e.g. VIA, SiS, ALI) chipsets.
Electrolytic capacitor reliability has been a problem throughout the electronics industry for the last 10 years or so, but even that should be less of a problem shortly. Gigabyte, for one, are introducing all-solid capacitor boards to eliminate this weak link in the chain.
Use the DVB Electronic Programme Guide retrieved over the air. At least, that's the way we'd do things in Europe.
No, because without the certification, secure/sensitive installations aren't allowed to use those flavours of BSD (or any other uncertified product). If there's no other way of performing a function, it might be justifiable, but it'll be a brave sysadmin that pursues such a course.
The above has no bearing on BSD's relative technical merits and demerits compared with OSs that have achieved CC certification.
I don't like Linux's software RAID implementation, as it immediately drops member devices out of their array in the event of a read error. I gather at least one implementation of software RAID in at least one flavour of BSD will immediately try to refresh the blocks that generated the read error using data from the other array members. This is the correct approach, IMNSHO, since doing it the Linux way means that if another array member encounters a read error whilst re-building the array, you lose the entire array.
If you're going to use JBOD, you probably might as well use RAID 0 and get better performance. The reliability will be lower than a single drive though (1/n, in fact).
RAID10 (stripes over mirrors) is the Rolls-Royce solution. It can tolerate upto (n/2) drives failing, and degraded performance is better than RAID 0+1, and array rebuilds are quicker than RAID 0+1 too. It doesn't come cheap, though, since you need at least 4 discs and you only get n*2 capacity.
It really depends on how important it is to maintain your media data; I have backups of the MP3s I've ripped (in addition to the original CDs) and my TV recordings are disposable, so I use a single 300GB disc in my MythTV box. I'm thinking of upgrading this to 2 * 500GB and putting TV recordings on one, and everything else on the other.
Only if your normal household heating is electrical. If you normally heat your home with gas, for example, you'll find that it's about 4 times cheaper per kWh than electricity. This makes sense if you consider the losses involved in generating the electricity from other sources of energy (e.g. gas), transmission losses and profit/convenience premium.
Actually, disk drives (both 5.25" and then-newfangled 3.5") were available for the Spectrum. Just not from Sinclair.
Which is probably why virtually no commercial games were available on floppy disk for the system.
OTOH, this did result in a wide array of "red button" gadgets (e.g. Romantic Robot's "Multiface") that used the NMI to stop the application/game whilst it was running, save its register state, overlay its ROM over the standard system ROM and jump into it. The system ROM usually included options for dumping the current state to microdrive or floppy, as well as various hacking/disassembly options. Later disk controllers (e.g. MGT's DISCiPLE and Plus D) started including such devices as standard.
Eventually, these NMI gadgets spread to other platforms, such as the Commodore 64 and Amstrad CPC, but I think it's fair to say they originated with the Spectrum due to the need for their existence on that platform.
Or people who weren't loaded with money. You were obviously one of those spoilt little gits. **** off back to your rich parents.
No, I didn't have a Spectrum, let alone a 16K model; but in the early days there was a major price difference, and one has to remember that the £175 for the 48K model would translate to almost £400 in today's money. The 16K model was "only" £125.
I can confirm this; as a 9 1/2 year old, at £99.99, my 16K Spectrum was only possible by grouping my parents' Christmas present with that of my grandparents. A friend got a 48K model at the same time by it being a shared present between him and his older brother. I planned to get a 32K upgrade to 48K a few months later as my birthday present, if I was still using it (I was, and continued to do so until June 1990 when I got my Amiga 500!). As it happened, around that time, the glue holding the metal keyboard to the plastic case gave way and we returned it under warranty. By then, the retailer only had 48K models for £129.99 and would exchange if we paid the £30 difference.
According to this inflation calculator, £175 in 1982 was worth between £413 (based on RPI) and £773 (based on GDP) in 2005 (the figure based upon average earnings is about halfway between those numbers), £125 was between £295 and £552. In 1983, £129.99 was between £293-£525 and £99.99 was between £226-£404. For the C64 and BBC B fans out there, their 1983 price (without any accessories, like C2N, 1541, RGB monitor) of £399 was £901-£1612 in 2005 prices.
That certainly reportedly happened in the Spectrum days too; 4164 64Kbit*1 DRAM ICs were constructed as two 32Kbit*1 cells internally. The manufacturer realized that these cells could be individually tested and the resulting ICs marketed as 4132 32Kbit*1 ICs, marked H or L according to whether high or the low half was functioning (which was why you needed a matching set of 8 in Spectrum RAM upgrade kits). The Spectrum's memory consisted of 8 4116 16Kbit*1 ICs for the lower 16KByte of memory (which was slower as CPU access was contended with the ULA as that's where the framebuffer lived), from 0x4000 to 0x7fff and 8 4132 32Kbit*1 ICs for 0x8000 to 0xffff. Eventually, the yields on 4164s rose and the supply of 4132s dried up, so fully-functioning 4164s were used for the upper 32KByte - as seen in my own vintage Spectrum (though the extra 32KByte was inaccesible without custom bank-switching circuitry).