The side effects of geoengineering could kill EVERYTHING.
The side effect of not geoengineering will kill everything.
Geoengineering is a skill we will need to master sooner or later. One day, whether we're the cause or not, this planet will not be inhabitable. We have three options: 1) direct our planet towards a consistently inhabitable state, 2) create an inhabitable world elsewhere, 3) die.
I don't really consider (3) to be much of an option, and (2) is so far beyond our current capabilities even experimentation is not a consideration. That leaves option (1).
Personally I'd rather we start our apprenticeship now by correcting our own effects on the environment rather than waiting until the planet makes it an unavoidable necessity regardless.
There should be at least some care taken before any major operation is undertaken, with that in mind.
It's sad that you think this might not be the case. We've spilled far worse into the oceans than iron, so try not to be offended when people that know what they're doing dismiss out of hand this hysteria over small scale experimentation.
I first heard about the electron migration problem as a reason for not overclocking back in the 386 days.
And yet my Celeron 300A has been running stable (first under OS/2, then XP) at 450Mhz since I bought it, 10 years ago.
Record uptime was ~650 days under XP, before a disk failure got it. And that disk was essentially "DOA" (visible bad sectors) but rather than RMA it I decided to see how long it lasted (obviously it's not a very important box).
PowerMax and NTFS/chkdsk recovered the initial damage and marked about 400k worth of visible bad sectors. It then survived another 4 years before SMART started reporting errors again, and it took another 6 months before it finally actually crashed.
SeaTools reset 102 problem sectors, NTFS/chkdsk reports no new visible bad sectors and recovered minor inconsistencies due to the crash. System is back online once again.
So it would seem modern tech is a little more resilient than we give it credit for, especially if the software doesn't shit itself as a result (this experiment would have failed miserably on ReiserFS).
The only time I would feel an obligation of support is if I've had to put up with endless whining about the superiority of open source and how there's no possible reason I could want closed source software, until I caved.
For the majority of users, OOo is roughly equivalent to Office. The only cases where I've run into trouble are with funky formatting and hardcore formulas/macros, which is pretty much power user territory. Most people either don't do complex operations, or do them by trial and error which works just as well under OOo as Office.
Also I suspect that most people still have/use the copy of Works/Office that came with their computer, which is probably also running Windows XP and is up to seven (7) years old. Their choice is: use the same old software, pay to upgrade (a much higher price than the OEM got it), or download free OOo. It might not be as good, but it's new and shiny and they didn't have to pay for it.
Obsessive compulsive upgrade disorder just bit MS in the arse.
As the article says, Microsoft documents the things they want you to know very well (more software for Windows == good), so it's not like they have a corporate culture of crap documentation. What they don't do is document things they don't want you to know, like formats and protocols, because that would allow you to use non-Microsoft software somewhere (== bad).
Since their documentation is obviously biased, they're in trouble again.
Linux has this capability through a recent innovation called a "package management system."
Right... we'll talk about this again when Myspace is full of RPMs and DEBs.
So, what's the difference between Microsoft Windows and Linux in this regard? It comes down to one word, "passwords."
Users will enter passwords on command like good little trained monkeys, so nothing has changed.
Password protection only saves you from, eg. browser exploits installing backdoors without your knowledge. Most Windows malware/crapware is installed deliberately at the request of the user, no raindance or blood sacrifice ritual can stop that without turning "their" computer into a black box appliance.
If a user without appropriate permissions attempts to install 3rd party software in a directory they're not permitted to run in, they're not permitted to install it. However, they are free to install software in their own home folder.
The OP already said they were running as Guest, so that's precisely what happened.
Fortunately, most software written for Linux can easily be installed in it's own context and will run properly.
You can install standard RedHat RPMs into your own home directory? And find/install updates automatically, resolve dependencies in your private space, etc? Awesome!
Regardless, it seems we've now established that running/installing software as a normal user, in areas writeable by normal users is acceptable, right? What kind of brain damage is preventing you from seeing how this is not more than enough access for malware/crapware mischief?
Run me through your thought pattern, because I can't understand where you're coming from and how you can possibly you arrive at a non-exploitable conclusion. As far as I can tell, it goes like this: user downloads omgponies.rpm from Myspace and either installs it to ~/omgponies or enters the system password for a root install. The first thing it does is run a post install script which then inserts spyware, crapware toolbars, or whatever into every dotfile orifice in the user's directory, or for a root install every damn where. User doesn't even have to run the program that was in it.
Right? Congratulations, welcome to having an operating system that someone other than nerds gives a shit about. How is this different from what is happening on Windows?
Privilege separation is a red herring on the desktop - administrative access is simply not necessary for most crapware to function. The main reason to run as Admin is purely defensive, to disable anti-virus and/or install hidden drivers, etc. so that the user can't get rid of it, rarely is Admin actually needed to perform its primary purpose. And should it ask for the Admin password, the user will supply the password because you, oh Lord of the System, have been training them to do it.
Almost every app needs full control of the system and full access to the registry.
Complete bullshit.
Have you even used Windows in the last 10 years at all? Especially in a corporate environment, Windows' security features are substantially better than other desktop OSs, the only issue is actually implementing them. Few will, because users scream bloody murder when they're told "you're not allowed to do that any more." But replace Windows with Linux and tell them instead that "it's not compatible," they'll accept it.
They had limited user accounts, it SHOULD NOT HAVE MADE A DIFFERENCE what they downloaded.
What does limited user accounts have to do with anything? User separation protects users from each other and the system from users but it doesn't protect the user from himself, on any desktop OS.
Like your parent said, security is a bandaid on windows, not built in.
It was built in from the beginning in the NT line. The security system in the kernel is better than any other desktop systems, it's only in userspace that it hasn't been implemented correctly because it's inconvenient to users. But that's a far cry from being a "bandaid" or not built-in. The only bandaid is making shit software work when security features that were always there are actually used.
Even the design guidelines for userspace apps that have been in place since Win95 are blithely ignored - it's only now that the rules are being enforced that problems show.
I don't know the entire reasons for that, I heard that in unix, services run as a normal user account, sandboxed away from causing damage while in Windows many services run as root - meaning only one has to be compromised for something malicious to gain control.
I don't see much difference between my Linux and Windows servers in that regard - both use privileged and non-privileged accounts depending on what resources the service needs to access. But that's pretty much irrelevant since the OP specifically said it was firewalled, so the network services aren't the attack vector.
It also can't be a privilege issue since they're running as guest (and I bet I can get root via local exploit easier on Linux than Windows). It can't be evil Intarweb Exploder because they're using FF. And it probably isn't even a real virus or trojan because they're running AVG, so it's likely that what he's got isn't a virus, worm or anything that AVG would remove, but simply crapware - toolbars, themes, cursors, tray widgets and other bullshit that "normal" people seem to like, things they intentionally install.
Default UAC in Vista might have finally changed that, but their machines still run the cheapest form of XP (without UAC) and it also does not get rid of the services issue.
UAC is privilege escalation. Which is pretty much irrelevant since his system got hosed even as a guest user.
Here's the simple version: as long as users are allowed to run any programs the system didn't come with, it will suffer this problem.
Linux is "immune" because installing software that didn't come from the vendor's own repository is basically impossible for normal people. Hell, most users probably couldn't figure out how to make anything they download executable. That will change if/when Linux gets popular - users will demand the ability to use 3rd party programs.
Bullshit. You must be a retard if you trust anything your kids say. They may be surfing the same sites, but they're downloading and executing ZOMG U MUST SEE THIS!!1 shit on the PC which isn't compatible with any other OS.
I haven't seen a virus on my PCs since my 286, which came preloaded with them, and my own deliberate HPAVC collection from the BBS days.
Sounds like something that solar thermal plants might have a lot of. Some {coal,gas,nuclear} plants already sell their excess heat to industry during the day, but they could also keep solar plants from going offline overnight..
A lot of us like permissions better than "Read, Write, Execute". Also, ACLs without dynamic inheritance are a nightmare waiting to happen. And lastly, userspace support for ACLs is still woeful on *nix - while getfacl/setfacl work well enough, GUI support is poor, archiver support is thin at best and many end-user apps still think it's OK to meddle with your permissions and inevitably screw it up because they only copy your permissions, not your ACLs (this happens more than you might expect, even word processors do it).
I strongly advise not using ACLs on Linux unless you're really sure they're the only option you have to get the results you want (and then make sure your intended results are worth the penalty). On Windows, use them as much as possible because runas is a piss-poor substitute for su/sudo.
Incidentally, this is the same reason you shouldn't use symlinks (junctions) on Windows unless you're really sure. While it's technically supported at the low level, the upper levels are basically oblivious and will carry on as though they were normal files and therefore fuck your system up one way or another (such as getting lost in a loop, backing up the same files multiple times, crossing filesystems, etc.).
There's two main types of fragmentation: file and free space. You really don't want your files to be fragmented, but free space fragmentation is an overrated problem to start with IMO (at least with modern disks) and trying to prevent it just increases file fragmentation when there's no room to extend them.
Defraggers that try to pack all your files into one end of the disk are probably doing more harm than good under normal circumstances. If seek speed is an issue at all, you're better off using partitions (eg. OS+Apps on one, bulk data on another).
There's also a difference between fragmenting, fragmenting badly and in how well a file system deals with fragmentation. All normal file systems fragment (and anyone who says otherwise is an idiot), but there's an undeniable difference between how each of them deal with it.
For example, HPFS (OS/2's native FS) stored data in "bands" (of 8MB, I think), each band having both metadata and file data. This fragmented the free space, but spreading the data across the partition with free space in between ensured most files either didn't fragment or the fragments weren't far apart. In short, this both reduced file fragmentation and reduced its impact on performance when it does (inevitably) happen.
NTFS on the other hand doesn't appear to use any physical or logical mitigation techniques and if I had to guess I'd say it just grabs the nearest free space closest to where ever the internal pointers were left from the last read/write.
It is especially bad at incrementally extending files, which is why many Windows applications that deal with large files (eg. P2P, VMWare, disk image utilities) often have an option to pre-allocate the full space.
Try it yourself: write a large file (eg. a few GB) with some relatively small block size (eg. 64k-1MB at a time) and see how much it fragments. Then try by creating a new file, immediately seek(EOF-1), write(NULL), then flush/seek(0) or close/reopen the file, and then fill in the actual data. The latter pre-allocation method will result in little to no fragmentation even on a nearly full file system.
The NTFS driver could most likely be much better than it is, though possibly at the expense of write speed/memory use.
While yellowcake alone is not considered potent enough for a so-called 'dirty bomb' -- a conventional explosive that disperses radioactive material -- it could stir widespread panic if incorporated in a blast.
So the primary hazard is mass panic.. exactly the same as a (uranium based) radiological dispersion device (dirty bomb) then. Also not too dissimilar to what the US have been doing for the last 5 years - shooting uranium all over the place.
Compression, multiuser encryption (with key recovery), reparse points, proper ACLs with dynamic inheritance (as I said, POSIX ACLs are primitive and not worth using)?
That's just bullshit. The simplest reason is that writing file systems is hard work and Unix programmers have trouble enough managing a stable one even on their home turf, let alone a platform they know little about and often despise.
Of course, there's a difference between using alternate file systems on a non-bootable partition vs a bootable one, but that's mostly due to the required support of the bootloader - a problem that exists even on *nix. If you only want to access a shared partition from Windows, have you tried this?
And finally Unix file systems are written for Unix (POSIX) operating systems, so while Windows isn't dependent on NTFS as such, it's dependent on a decent ACL implementation (POSIX ACLs are crude and basically worthless with rare exception; believe me, I tried) and some other advanced features depending on what you're doing.
The fact that Windows isn't Unix is neither bug, nor feature, nor evil conspiracy; it's just what it is. Unix maps no better to Windows than to VMS or OS/390.
Does it really matter? Once you expose the instruction set, it's set in stone. That'll lead us back to exactly where we are in another 30 years. As these instructions are internal, they're free to change to suit the technology of the execution units in each processor generation. And presumably because CISC instructions are bigger, they're more descriptive and the decoder can optimise them better. Intel already tried making the compiler do the optimisation - didn't work out so well.
If Intel wants into the market for real, I think ATI/nVidia should be plenty afraid.
Intel not only has their own fabrication plants, but they're high end ones not three or four sizes behind. Apple (of all companies) switched to Intel's CPUs for a reason - they have the capacity and the technology to produce lots of fast, low power components and a market base large enough (CPUs and chips of all kinds) to keep their GPU technology ahead of the curve.
With the market tending towards lower power, mobile computing and console gaming.. that's bad news for everyone except Intel. AMD/ATI and nVidia (via IBM) are all at least one step behind in their fabrication technology.
The side effect of not geoengineering will kill everything.
Geoengineering is a skill we will need to master sooner or later. One day, whether we're the cause or not, this planet will not be inhabitable. We have three options: 1) direct our planet towards a consistently inhabitable state, 2) create an inhabitable world elsewhere, 3) die.
I don't really consider (3) to be much of an option, and (2) is so far beyond our current capabilities even experimentation is not a consideration. That leaves option (1).
Personally I'd rather we start our apprenticeship now by correcting our own effects on the environment rather than waiting until the planet makes it an unavoidable necessity regardless.
It's sad that you think this might not be the case. We've spilled far worse into the oceans than iron, so try not to be offended when people that know what they're doing dismiss out of hand this hysteria over small scale experimentation.
I first heard about the electron migration problem as a reason for not overclocking back in the 386 days.
And yet my Celeron 300A has been running stable (first under OS/2, then XP) at 450Mhz since I bought it, 10 years ago.
Record uptime was ~650 days under XP, before a disk failure got it. And that disk was essentially "DOA" (visible bad sectors) but rather than RMA it I decided to see how long it lasted (obviously it's not a very important box).
PowerMax and NTFS/chkdsk recovered the initial damage and marked about 400k worth of visible bad sectors. It then survived another 4 years before SMART started reporting errors again, and it took another 6 months before it finally actually crashed.
SeaTools reset 102 problem sectors, NTFS/chkdsk reports no new visible bad sectors and recovered minor inconsistencies due to the crash. System is back online once again.
So it would seem modern tech is a little more resilient than we give it credit for, especially if the software doesn't shit itself as a result (this experiment would have failed miserably on ReiserFS).
</anecdote>
"All great truths begin as blasphemies."
(George Bernard Shaw)
Anyone with ubiquitous network access? They're called netbooks for a reason.
I have plenty of storage and processing power elsewhere, I don't need battery sucking features on my portable terminal.
Netbook == PADD with a keyboard.
The only time I would feel an obligation of support is if I've had to put up with endless whining about the superiority of open source and how there's no possible reason I could want closed source software, until I caved.
"You must be new here."
For the majority of users, OOo is roughly equivalent to Office. The only cases where I've run into trouble are with funky formatting and hardcore formulas/macros, which is pretty much power user territory. Most people either don't do complex operations, or do them by trial and error which works just as well under OOo as Office.
Also I suspect that most people still have/use the copy of Works/Office that came with their computer, which is probably also running Windows XP and is up to seven (7) years old. Their choice is: use the same old software, pay to upgrade (a much higher price than the OEM got it), or download free OOo. It might not be as good, but it's new and shiny and they didn't have to pay for it.
Obsessive compulsive upgrade disorder just bit MS in the arse.
Would something like NetSerial work?
[old device]--[serial]--[netserial]--[internet]--[netserial]--[serial]--[old device]
As the article says, Microsoft documents the things they want you to know very well (more software for Windows == good), so it's not like they have a corporate culture of crap documentation. What they don't do is document things they don't want you to know, like formats and protocols, because that would allow you to use non-Microsoft software somewhere (== bad).
Since their documentation is obviously biased, they're in trouble again.
But the last study said salt was bad for you...
Right... we'll talk about this again when Myspace is full of RPMs and DEBs.
Users will enter passwords on command like good little trained monkeys, so nothing has changed.
Password protection only saves you from, eg. browser exploits installing backdoors without your knowledge. Most Windows malware/crapware is installed deliberately at the request of the user, no raindance or blood sacrifice ritual can stop that without turning "their" computer into a black box appliance.
The OP already said they were running as Guest, so that's precisely what happened.
You can install standard RedHat RPMs into your own home directory? And find/install updates automatically, resolve dependencies in your private space, etc? Awesome!
Regardless, it seems we've now established that running/installing software as a normal user, in areas writeable by normal users is acceptable, right? What kind of brain damage is preventing you from seeing how this is not more than enough access for malware/crapware mischief?
Run me through your thought pattern, because I can't understand where you're coming from and how you can possibly you arrive at a non-exploitable conclusion. As far as I can tell, it goes like this: user downloads omgponies.rpm from Myspace and either installs it to ~/omgponies or enters the system password for a root install. The first thing it does is run a post install script which then inserts spyware, crapware toolbars, or whatever into every dotfile orifice in the user's directory, or for a root install every damn where. User doesn't even have to run the program that was in it.
Right? Congratulations, welcome to having an operating system that someone other than nerds gives a shit about. How is this different from what is happening on Windows?
Privilege separation is a red herring on the desktop - administrative access is simply not necessary for most crapware to function. The main reason to run as Admin is purely defensive, to disable anti-virus and/or install hidden drivers, etc. so that the user can't get rid of it, rarely is Admin actually needed to perform its primary purpose. And should it ask for the Admin password, the user will supply the password because you, oh Lord of the System, have been training them to do it.
Complete bullshit.
Have you even used Windows in the last 10 years at all? Especially in a corporate environment, Windows' security features are substantially better than other desktop OSs, the only issue is actually implementing them. Few will, because users scream bloody murder when they're told "you're not allowed to do that any more." But replace Windows with Linux and tell them instead that "it's not compatible," they'll accept it.
What does limited user accounts have to do with anything? User separation protects users from each other and the system from users but it doesn't protect the user from himself, on any desktop OS.
It was built in from the beginning in the NT line. The security system in the kernel is better than any other desktop systems, it's only in userspace that it hasn't been implemented correctly because it's inconvenient to users. But that's a far cry from being a "bandaid" or not built-in. The only bandaid is making shit software work when security features that were always there are actually used.
Even the design guidelines for userspace apps that have been in place since Win95 are blithely ignored - it's only now that the rules are being enforced that problems show.
I don't see much difference between my Linux and Windows servers in that regard - both use privileged and non-privileged accounts depending on what resources the service needs to access. But that's pretty much irrelevant since the OP specifically said it was firewalled, so the network services aren't the attack vector.
It also can't be a privilege issue since they're running as guest (and I bet I can get root via local exploit easier on Linux than Windows). It can't be evil Intarweb Exploder because they're using FF. And it probably isn't even a real virus or trojan because they're running AVG, so it's likely that what he's got isn't a virus, worm or anything that AVG would remove, but simply crapware - toolbars, themes, cursors, tray widgets and other bullshit that "normal" people seem to like, things they intentionally install.
UAC is privilege escalation. Which is pretty much irrelevant since his system got hosed even as a guest user.
Here's the simple version: as long as users are allowed to run any programs the system didn't come with, it will suffer this problem.
Linux is "immune" because installing software that didn't come from the vendor's own repository is basically impossible for normal people. Hell, most users probably couldn't figure out how to make anything they download executable. That will change if/when Linux gets popular - users will demand the ability to use 3rd party programs.
Bullshit. You must be a retard if you trust anything your kids say. They may be surfing the same sites, but they're downloading and executing ZOMG U MUST SEE THIS!!1 shit on the PC which isn't compatible with any other OS.
I haven't seen a virus on my PCs since my 286, which came preloaded with them, and my own deliberate HPAVC collection from the BBS days.
A Brief Index Of Difficulty
Technology giveth and technology taketh away ;)
"Percussive maintenance"
Sounds like something that solar thermal plants might have a lot of. Some {coal,gas,nuclear} plants already sell their excess heat to industry during the day, but they could also keep solar plants from going offline overnight..
A lot of us like permissions better than "Read, Write, Execute". Also, ACLs without dynamic inheritance are a nightmare waiting to happen. And lastly, userspace support for ACLs is still woeful on *nix - while getfacl/setfacl work well enough, GUI support is poor, archiver support is thin at best and many end-user apps still think it's OK to meddle with your permissions and inevitably screw it up because they only copy your permissions, not your ACLs (this happens more than you might expect, even word processors do it).
I strongly advise not using ACLs on Linux unless you're really sure they're the only option you have to get the results you want (and then make sure your intended results are worth the penalty). On Windows, use them as much as possible because runas is a piss-poor substitute for su/sudo.
Incidentally, this is the same reason you shouldn't use symlinks (junctions) on Windows unless you're really sure. While it's technically supported at the low level, the upper levels are basically oblivious and will carry on as though they were normal files and therefore fuck your system up one way or another (such as getting lost in a loop, backing up the same files multiple times, crossing filesystems, etc.).
There's two main types of fragmentation: file and free space. You really don't want your files to be fragmented, but free space fragmentation is an overrated problem to start with IMO (at least with modern disks) and trying to prevent it just increases file fragmentation when there's no room to extend them.
Defraggers that try to pack all your files into one end of the disk are probably doing more harm than good under normal circumstances. If seek speed is an issue at all, you're better off using partitions (eg. OS+Apps on one, bulk data on another).
There's also a difference between fragmenting, fragmenting badly and in how well a file system deals with fragmentation. All normal file systems fragment (and anyone who says otherwise is an idiot), but there's an undeniable difference between how each of them deal with it.
For example, HPFS (OS/2's native FS) stored data in "bands" (of 8MB, I think), each band having both metadata and file data. This fragmented the free space, but spreading the data across the partition with free space in between ensured most files either didn't fragment or the fragments weren't far apart. In short, this both reduced file fragmentation and reduced its impact on performance when it does (inevitably) happen.
NTFS on the other hand doesn't appear to use any physical or logical mitigation techniques and if I had to guess I'd say it just grabs the nearest free space closest to where ever the internal pointers were left from the last read/write.
It is especially bad at incrementally extending files, which is why many Windows applications that deal with large files (eg. P2P, VMWare, disk image utilities) often have an option to pre-allocate the full space.
Try it yourself: write a large file (eg. a few GB) with some relatively small block size (eg. 64k-1MB at a time) and see how much it fragments. Then try by creating a new file, immediately seek(EOF-1), write(NULL), then flush/seek(0) or close/reopen the file, and then fill in the actual data. The latter pre-allocation method will result in little to no fragmentation even on a nearly full file system.
The NTFS driver could most likely be much better than it is, though possibly at the expense of write speed/memory use.
So the primary hazard is mass panic.. exactly the same as a (uranium based) radiological dispersion device (dirty bomb) then. Also not too dissimilar to what the US have been doing for the last 5 years - shooting uranium all over the place.
Compression, multiuser encryption (with key recovery), reparse points, proper ACLs with dynamic inheritance (as I said, POSIX ACLs are primitive and not worth using)?
1) FAT is a very simple file system and the Linux implementation of NTFS is even less complete than ext2 is on Windows.
2) Linux users have a larger need/want to run FAT/NTFS than Windows users need/want to run ext2. Necessity, invention, etc.
3) Obviously, Windows is case retentive not case sensitive. As I said, Windows isn't Unix so Unix file systems aren't going to port well.
If anything, NTFS would port easier to Linux because NTFS is a much more feature rich file system than most *nix filesystems.
That's just bullshit. The simplest reason is that writing file systems is hard work and Unix programmers have trouble enough managing a stable one even on their home turf, let alone a platform they know little about and often despise.
Of course, there's a difference between using alternate file systems on a non-bootable partition vs a bootable one, but that's mostly due to the required support of the bootloader - a problem that exists even on *nix. If you only want to access a shared partition from Windows, have you tried this?
And finally Unix file systems are written for Unix (POSIX) operating systems, so while Windows isn't dependent on NTFS as such, it's dependent on a decent ACL implementation (POSIX ACLs are crude and basically worthless with rare exception; believe me, I tried) and some other advanced features depending on what you're doing.
The fact that Windows isn't Unix is neither bug, nor feature, nor evil conspiracy; it's just what it is. Unix maps no better to Windows than to VMS or OS/390.
Does it really matter? Once you expose the instruction set, it's set in stone. That'll lead us back to exactly where we are in another 30 years. As these instructions are internal, they're free to change to suit the technology of the execution units in each processor generation. And presumably because CISC instructions are bigger, they're more descriptive and the decoder can optimise them better. Intel already tried making the compiler do the optimisation - didn't work out so well.
It's only pale grey at 6500K. Set your monitor to 7500K or more and it looks more like a girly shade of purple (lavender).
If Intel wants into the market for real, I think ATI/nVidia should be plenty afraid.
Intel not only has their own fabrication plants, but they're high end ones not three or four sizes behind. Apple (of all companies) switched to Intel's CPUs for a reason - they have the capacity and the technology to produce lots of fast, low power components and a market base large enough (CPUs and chips of all kinds) to keep their GPU technology ahead of the curve.
With the market tending towards lower power, mobile computing and console gaming.. that's bad news for everyone except Intel. AMD/ATI and nVidia (via IBM) are all at least one step behind in their fabrication technology.