Because I flat out refuse to believe the entire team doesn't know any better.
It's way more common then you'd think. I worked for a company back in 2000, with close to 20 developers. Not a single one of them knew how to do version control. Instead, they all resorted to making copies of files, tacking on dates or times or just numbers, and relying on the backup tapes if they had to undo a particular change. It was hellish and you'd hear at least one conversation per week where they were trying to figure out who had the latest version of XYZ.
I rolled out VSS (hey, it was 2000, our choices were limited) with SourceOffSite for the remote workers. If I did it today, it would be either Hg, git or svn.
Very few schools back in the 90s or early part of the decade taught VCS concepts or forced students to use them. This is slowly changing with the advent of things like 'github' which has a big mindshare and introduces people to the concept of VCS.
Our approach (we use SVN) is to create working copies for every single client under a C:\Clients\xyz scheme. Where 'xyz' is the 3-letter codename for each client.
Each of those working copies is created with a script (stored in a 'svn-scripts' repository) that does a "file children only" checkout. The svn command for that is "svn checkout --depth files URL targetdir".
Because we only bring down immediate file children in the root of the repository, it doesn't take up much space. And bringing down a particular project folder from within the repository is made much easier.
1. Right click within the working copy -> TortoiseSVN -> Repo Browser
2. Find what you want, r-click, and "Update to Revision".
3. Make the depth "working copy" to bring everything from that point and below down to your working copy.
After which you work with the working copy as normal (commit, update, etc.). When you're done with the project, you can erase it off your hard drive with another "update to revision", this time picking "exclude".
(Yes, it's a little obtuse how to work with sparse working copies and I wish they'd improve it. But it does work without too much effort.)
Actually, as long as you insulated VSS from clients trying to update things over a flaky network connection, it wasn't that bad (and somewhat resilient).
The best approach was to put SourceOffSite in front of your VSS repository. Then force all clients to use the SOS client over the network instead of putting the VSS repository on a network share.
(We went from monthly issues with corruption to maybe once per year. Of course, SOS was not cheap, so once SVN matured we migrated away from VSS/SOS.)
Create one repository per project (or per client), with a sensible naming scheme for the SVN URLs. For instance, put your repositories under/var/svn or/srv/svn, and give them all a 'proj-XYZ' style name (or 'client-XYZ').
We store all of our projects in SVN as well. Most of the files that end up in there are Word documents, Excel spreadsheets, plus a bit of HTML, scripts, and other things. So we're dealing with less technical users as well.
SVN has "sparse directory" support where your initial checkout is only "file children". In order to bring down deeper directories, you use TortoiseSVN repo-browser and tell it to bring down directory XYZ/ABC/123 (and give it a depth). So your users don't need to bring everything down, they can focus on a particular folder inside the repository. And change their minds later.
Toss WebSVN into the loop and you can give your users read-only views of all of the repositories via a web browser. This serves well for times when they want file XYZ, but don't want to jump through doing a sparse "update-to-revision" or don't have a checkout of a particular project.
git is a rather poor choice for binaries due to the way it stores things. SVN is the better choice for binaries, especially for a situation where you want a central repository server.
But really, the answer is "nearly any centralized version control system" is a better choice then trying to rsync/unison stuff around. With the advantage that everyone *knows* they have the latest (by asking the server) and you get full revision history for everything.
The boxed processor I bought (FX4300, quad @ 3.8ghz OC'd to 4.1ghz) is using the stock AMD HSF that it came with. It usually runs around 42C and gets up to maybe 53-54C under a load that pegs all 4 cores (movie encoding, which I often do).
Here's a dirty little secret about the "temperatures" that are reported by AMD (and probably Intel) processors. They are *not* calibrated against anything. You can't say that the processor runs at 53-54C with any certainty (it can be +/- 10% or more when compared to a calibrated sensor), all you can say is that it runs about 11-12C warmer under load then idle.
Very few temperature sensors inside of PCs are calibrated. You can have multiple sensors, all within an inch of each other, all taking the same airflow, and one will report a 5C difference.
Does CentOS actually do that? I thought that the only thing they did was provide - for no cost - the CDs or downloads of RHEL rebranded, and then let the 'customer' handle it on his own. Which would imply that the Admins presumably already had whatever expertise is needed.
We moved to CentOS for one reason: It's basically the same environment as RHEL, which means that if we ever need to move up to the paid support model, we already know the quirks of the environment.
There's only like (4) possible choices for Linux server distros, Debian (Stable), SuSE, RHEL/CentOS, and maybe Mandrake. Just about everyone who does paid work on Linux knows either Debian or RHEL. There are dozens and dozens of books out there covering those two distros, but you'd be hard pressed to find a dozen books on the other distros (unless they're a clone of one of the big ones).
Which also means that I'm very likely to turn up an answer via Google, or be able to find the answer on my bookshelf, when I run into an operating system issue.
The only real downside to RHEL/CentOS is that they are slow to change and have multi-year release cycles. Which means if you want a later version of Postfix or something, you either need to bring it in from a 3rd party repository (using the includepkgs= line in your repository definition, or compile it from source. So installing XYZ can be a bit of an adventure at figuring out what packages need to be added to the "includepkgs=" line.
(But using includepkgs= and only pulling in the absolute minimum from 3rd party repositories makes for a much more stable server. So it's worth the trouble.)
For new laptops these days, we use 80% or 85% as the threshold before a charge cycle takes place. The default for Lenovo is 96%. Most of our users spend 80% of their time tethered to a power cable, and charging every few days after it trickles down to 96% is just silly (and bad for the battery).
#1 is because most (all?) Li-Ion batteries can only be charged a few hundred times. Even a partial charge from 95% back up to 100% can count as a "charge cycle". So one tactic is to change your power management settings so that it doesn't start a charge cycle until the battery hits 80-90% levels.
For devices using Li-Ion, try and adjust your charger settings so that the battery has to drain down to 85-90% (instead of 95-98%) before a charging cycle starts. Fewer charging cycles per year gives you more years out of the battery.
This trick works best if you spend most of your time hooked up to external power. But is still beneficial for devices that get left plugged in for a few days at a time between bouts of heavy use.
The main reason why Linux is more secure is history. Linux is descended from Unix, and Unix spent its formative years in University labs where students would routinely prank each other. Of necessity, Unix grew up with security being an issue almost from Day 1.
That's a bit revisionist. Early unix was horribly insecure at multi-user stuff. It took a long while before security became something important in design.
Easiest example to name is the storage of passwords in/etc/passwd. Since the file was readable by everyone, it was easy to grab the hashes and perform offline attacks. I'm not even sure that early password hashes were salted in unix, which meant that if you could crack one account you could easily see that your password would match accounts X, Y and Z.
Any scenario that might present a threat to Chrome's password storage would compromise Firefox's just as easily-- once the master password is input, the keystore is unlocked.
How about the scenario of "stolen / lost hard drive (or computer)".
They've got the physical hardware, which means software-based permissions are easily bypassed and they can easily read off the password file.
The advantage of the master passphrase comes into play in cases of stolen computers / hard drives / backup tapes. Where relying on disk-based user-account permissions won't save your bacon, but the attacker won't be planting malicious software on your system either.
Sadly, chaining three methods doesn't make things 3x more secure (either for hashes or encryption). Read Practical Cryptograpy by Bruce Schneier for the details. At least, I think that's the book that talks about it, it's been a few years.
Well, even funnier is that is now biting them in the ass from the opposite direction. When a consumer looks at (3) tablets from Apple / Android / Microsoft, they're going to want to know if it runs hip-application-XYZ.
Which, odds are high, that app is only available on iOS and/or Android.
Used to be that you bought Windows because that was what the application (that you desired) ran on. It fails to translate to the mobile world because of Microsoft's numerous missteps over the last decade. Every time MS would refresh the platform (WinCE had multiple versions, same with Windows Mobile), you had to buy all new software because your old software wouldn't run.
Most of what I can get in the iPad 4 I can get in the Asus Transformer series (TF700T). Advantage over the iPad was the microSD slot as well as a few other things (such as the keyboard option).
It's very hit/miss with optical media. Even with the "good" stuff (Taiyo-Yuden) you might have bought a bad batch or a counterfeit batch.
The smart people added extra redundancy to their disks instead of relying on the built-in error-correction at the media level. Things like PAR2 or WinRAR with parity blocks. That way, even if a few blocks go bad, you can reconstruct the missing data and get all of your data back. Back when we did a lot of optical storage, our standard was 5% or 10% parity data on each disk.
Plus there's the whole concept of multi-generational backups where any single piece of data resides on at least 3 different platters.
If the data set changes slowly, why not just use rdiff-backup or storing the files into a version control system? As long as you don't prune off old revisions in the rdiff-backup, you can go back to any point in time. With a version control system, you can also go back to any point in time, but you are more limited when it comes to trimming out stuff that is 7 years old.
Both solutions offer hashes of the data so that you can verify that the backups have not suffered from bit-rot. Both (depending on how the version control system stores its information) are easily rsync'd across the network / internet.
And a T1 line (1.5Mbps) can transfer about 500MB/hr. Or about 12GB/day. If the dataset changes slowly, you can move the data on disk to the new site, then just rsync the changes each day.
Or better, combine the use of rdiff-backup with the optical media. Assuming that the rdiff-backup target directory fits on a single platter of media, you get the best of both worlds. You can physically go back and grab the disc from 7 years ago, or you can grab the latest disc and go back to any point in time in the last 7 years.
That way, if a single piece of optical media fails or goes missing, you can simply grab any piece of optical media that contains the history that you want.
You need to segregate your passwords into a few buckets:
- The OMG I'm screwed bucket. Things like your financial passwords, administration account and primary email account passwords. Those should be memorable, complex (mix of upper/lower/numbers at a minimum), as long as reasonably possible (at least 10-12 chars, 15-18 would be better). Don't ever reuse one of those elsewhere. If you save them to a file, use a text file where you have pasted in a GPG encryption ASCII encoded block. Never save them in plain text. Keep a copy in a sealed envelope in your safe deposit box or personal safe. Don't let the browser remember them. (In general, you can probably remember most of these with a bit of effort as there's only a small handful of passwords that fall into this category.)
- The ones that would let someone impersonate you, in a place that matters such as a public event or in business. This includes anything that is tied to a payment method. For these, you want to go random (shell script, rolling dice, whatever) and go long (15-30 characters) with mixed-case, numbers and symbols. Every site should have a unique password, with no reuse between sites. It doesn't matter much if you use Keypass or Mozilla's password safe or GPG to store them, as long as you secure that storage with a long passphrase. I suggest keeping a backup of those passwords in a text file protected with GPG (one file per account/site).
- The sites that just don't matter. Most forums or any website where you aren't tying a payment method to the account. Generate a random password and let the browser remember it. A password reset is only a click away and if someone does hack the site and get your password (or its hash), all they have is a long string of gibberish that isn't used anywhere else.
It isn't just laziness. It's also money. It is difficult to get a balanced diet on a low budget. (Not impossible, but difficult.)
That's an education issue and not a problem of what is sold at the grocer. Stick to things like rice, potatoes and pasta as a base, add in fresh or frozen vegetables, along with beans/lentils. Keep a basic spice rack. Stay away from the frozen meals, most things in a can, sodas, snack foods and other high-calorie low-nutrition junk.
Learn to cook dishes from scratch. Stay away from (most) fast food. The main downside is that you need to spend more time prepping and cooking each day rather then just popping something in a microwave.
But they more than made up that loss on games sales. Consoles are traditionally sold at a loss.
And they were trying to get 30% of the take from Windows RT application sales. So they should have done it the same as the XBox rollout. Sell the hardware at a loss and build enough of a market so that developers are willing to participate int he Windows RT application store.
And they all flopped and were discontinued. Largely because of lack of compatibility with x86 Windows; you could run some x86 programs (slowly) on the non-x86 builds, but then why not just buy an x86 machine in the first place?
Which was the absolute genius of the early AMD Opteron and AMD64 processors. You could get great performance for your 32bit x86 applications, while running on a CPU that was capable of 64bit.
And they ate Intel's lunch for a while in the server-side where companies wanted to start moving towards 64bit capable hardware and off of 32bit. If you were buying server hardware c2006, your choice was a 32bit Intel CPU or a 64bit AMD CPU. Intel wanted you to use Itanium for your 64bit stuff, companies said "screw that" and installed Opteron 64bit CPUs instead.
As a result, as we moved from 32 bit XP to 64bit Win7, we didn't have to swap out the hardware. For machines built in 2006-2008 time-frame. We just put in a bit more RAM and a SSD drive and they're good to go for a few more years.
Slashdot Mirror
TortoiseSVN is smart enough with MSWord documents to call Word's diff engine.
Still not as smart as keeping your documentation in something more portable, like lex/tex or XHTML.
Because I flat out refuse to believe the entire team doesn't know any better.
It's way more common then you'd think. I worked for a company back in 2000, with close to 20 developers. Not a single one of them knew how to do version control. Instead, they all resorted to making copies of files, tacking on dates or times or just numbers, and relying on the backup tapes if they had to undo a particular change. It was hellish and you'd hear at least one conversation per week where they were trying to figure out who had the latest version of XYZ.
I rolled out VSS (hey, it was 2000, our choices were limited) with SourceOffSite for the remote workers. If I did it today, it would be either Hg, git or svn.
Very few schools back in the 90s or early part of the decade taught VCS concepts or forced students to use them. This is slowly changing with the advent of things like 'github' which has a big mindshare and introduces people to the concept of VCS.
Our approach (we use SVN) is to create working copies for every single client under a C:\Clients\xyz scheme. Where 'xyz' is the 3-letter codename for each client.
Each of those working copies is created with a script (stored in a 'svn-scripts' repository) that does a "file children only" checkout. The svn command for that is "svn checkout --depth files URL targetdir".
Because we only bring down immediate file children in the root of the repository, it doesn't take up much space. And bringing down a particular project folder from within the repository is made much easier.
1. Right click within the working copy -> TortoiseSVN -> Repo Browser
2. Find what you want, r-click, and "Update to Revision".
3. Make the depth "working copy" to bring everything from that point and below down to your working copy.
After which you work with the working copy as normal (commit, update, etc.). When you're done with the project, you can erase it off your hard drive with another "update to revision", this time picking "exclude".
(Yes, it's a little obtuse how to work with sparse working copies and I wish they'd improve it. But it does work without too much effort.)
Maybe btrfs... can't remember if that is in the spec.
You can also do fun things with the various VCS such as mounting them as file systems (svnfs, gitfs, etc.).
Actually, as long as you insulated VSS from clients trying to update things over a flaky network connection, it wasn't that bad (and somewhat resilient).
The best approach was to put SourceOffSite in front of your VSS repository. Then force all clients to use the SOS client over the network instead of putting the VSS repository on a network share.
(We went from monthly issues with corruption to maybe once per year. Of course, SOS was not cheap, so once SVN matured we migrated away from VSS/SOS.)
SVN (with TortoiseSVN) is the better choice.
/var/svn or /srv/svn, and give them all a 'proj-XYZ' style name (or 'client-XYZ').
Create one repository per project (or per client), with a sensible naming scheme for the SVN URLs. For instance, put your repositories under
We store all of our projects in SVN as well. Most of the files that end up in there are Word documents, Excel spreadsheets, plus a bit of HTML, scripts, and other things. So we're dealing with less technical users as well.
SVN has "sparse directory" support where your initial checkout is only "file children". In order to bring down deeper directories, you use TortoiseSVN repo-browser and tell it to bring down directory XYZ/ABC/123 (and give it a depth). So your users don't need to bring everything down, they can focus on a particular folder inside the repository. And change their minds later.
Toss WebSVN into the loop and you can give your users read-only views of all of the repositories via a web browser. This serves well for times when they want file XYZ, but don't want to jump through doing a sparse "update-to-revision" or don't have a checkout of a particular project.
git is a rather poor choice for binaries due to the way it stores things. SVN is the better choice for binaries, especially for a situation where you want a central repository server.
But really, the answer is "nearly any centralized version control system" is a better choice then trying to rsync/unison stuff around. With the advantage that everyone *knows* they have the latest (by asking the server) and you get full revision history for everything.
The boxed processor I bought (FX4300, quad @ 3.8ghz OC'd to 4.1ghz) is using the stock AMD HSF that it came with. It usually runs around 42C and gets up to maybe 53-54C under a load that pegs all 4 cores (movie encoding, which I often do).
Here's a dirty little secret about the "temperatures" that are reported by AMD (and probably Intel) processors. They are *not* calibrated against anything. You can't say that the processor runs at 53-54C with any certainty (it can be +/- 10% or more when compared to a calibrated sensor), all you can say is that it runs about 11-12C warmer under load then idle.
Very few temperature sensors inside of PCs are calibrated. You can have multiple sensors, all within an inch of each other, all taking the same airflow, and one will report a 5C difference.
Only the "enterprise" level drives. The Intel DC S3500 series, for one. Most consumer level drives do not have capacitors.
Does CentOS actually do that? I thought that the only thing they did was provide - for no cost - the CDs or downloads of RHEL rebranded, and then let the 'customer' handle it on his own. Which would imply that the Admins presumably already had whatever expertise is needed.
We moved to CentOS for one reason: It's basically the same environment as RHEL, which means that if we ever need to move up to the paid support model, we already know the quirks of the environment.
There's only like (4) possible choices for Linux server distros, Debian (Stable), SuSE, RHEL/CentOS, and maybe Mandrake. Just about everyone who does paid work on Linux knows either Debian or RHEL. There are dozens and dozens of books out there covering those two distros, but you'd be hard pressed to find a dozen books on the other distros (unless they're a clone of one of the big ones).
Which also means that I'm very likely to turn up an answer via Google, or be able to find the answer on my bookshelf, when I run into an operating system issue.
The only real downside to RHEL/CentOS is that they are slow to change and have multi-year release cycles. Which means if you want a later version of Postfix or something, you either need to bring it in from a 3rd party repository (using the includepkgs= line in your repository definition, or compile it from source. So installing XYZ can be a bit of an adventure at figuring out what packages need to be added to the "includepkgs=" line.
(But using includepkgs= and only pulling in the absolute minimum from 3rd party repositories makes for a much more stable server. So it's worth the trouble.)
For new laptops these days, we use 80% or 85% as the threshold before a charge cycle takes place. The default for Lenovo is 96%. Most of our users spend 80% of their time tethered to a power cable, and charging every few days after it trickles down to 96% is just silly (and bad for the battery).
For a few reasons:
#1 is because most (all?) Li-Ion batteries can only be charged a few hundred times. Even a partial charge from 95% back up to 100% can count as a "charge cycle". So one tactic is to change your power management settings so that it doesn't start a charge cycle until the battery hits 80-90% levels.
#2 is heat.
For devices using Li-Ion, try and adjust your charger settings so that the battery has to drain down to 85-90% (instead of 95-98%) before a charging cycle starts. Fewer charging cycles per year gives you more years out of the battery.
This trick works best if you spend most of your time hooked up to external power. But is still beneficial for devices that get left plugged in for a few days at a time between bouts of heavy use.
The main reason why Linux is more secure is history. Linux is descended from Unix, and Unix spent its formative years in University labs where students would routinely prank each other. Of necessity, Unix grew up with security being an issue almost from Day 1.
/etc/passwd. Since the file was readable by everyone, it was easy to grab the hashes and perform offline attacks. I'm not even sure that early password hashes were salted in unix, which meant that if you could crack one account you could easily see that your password would match accounts X, Y and Z.
That's a bit revisionist. Early unix was horribly insecure at multi-user stuff. It took a long while before security became something important in design.
Easiest example to name is the storage of passwords in
Any scenario that might present a threat to Chrome's password storage would compromise Firefox's just as easily-- once the master password is input, the keystore is unlocked.
How about the scenario of "stolen / lost hard drive (or computer)".
They've got the physical hardware, which means software-based permissions are easily bypassed and they can easily read off the password file.
The advantage of the master passphrase comes into play in cases of stolen computers / hard drives / backup tapes. Where relying on disk-based user-account permissions won't save your bacon, but the attacker won't be planting malicious software on your system either.
Sadly, chaining three methods doesn't make things 3x more secure (either for hashes or encryption). Read Practical Cryptograpy by Bruce Schneier for the details. At least, I think that's the book that talks about it, it's been a few years.
Well, even funnier is that is now biting them in the ass from the opposite direction. When a consumer looks at (3) tablets from Apple / Android / Microsoft, they're going to want to know if it runs hip-application-XYZ.
Which, odds are high, that app is only available on iOS and/or Android.
Used to be that you bought Windows because that was what the application (that you desired) ran on. It fails to translate to the mobile world because of Microsoft's numerous missteps over the last decade. Every time MS would refresh the platform (WinCE had multiple versions, same with Windows Mobile), you had to buy all new software because your old software wouldn't run.
Most of what I can get in the iPad 4 I can get in the Asus Transformer series (TF700T). Advantage over the iPad was the microSD slot as well as a few other things (such as the keyboard option).
It's very hit/miss with optical media. Even with the "good" stuff (Taiyo-Yuden) you might have bought a bad batch or a counterfeit batch.
The smart people added extra redundancy to their disks instead of relying on the built-in error-correction at the media level. Things like PAR2 or WinRAR with parity blocks. That way, even if a few blocks go bad, you can reconstruct the missing data and get all of your data back. Back when we did a lot of optical storage, our standard was 5% or 10% parity data on each disk.
Plus there's the whole concept of multi-generational backups where any single piece of data resides on at least 3 different platters.
If the data set changes slowly, why not just use rdiff-backup or storing the files into a version control system? As long as you don't prune off old revisions in the rdiff-backup, you can go back to any point in time. With a version control system, you can also go back to any point in time, but you are more limited when it comes to trimming out stuff that is 7 years old.
Both solutions offer hashes of the data so that you can verify that the backups have not suffered from bit-rot. Both (depending on how the version control system stores its information) are easily rsync'd across the network / internet.
And a T1 line (1.5Mbps) can transfer about 500MB/hr. Or about 12GB/day. If the dataset changes slowly, you can move the data on disk to the new site, then just rsync the changes each day.
Or better, combine the use of rdiff-backup with the optical media. Assuming that the rdiff-backup target directory fits on a single platter of media, you get the best of both worlds. You can physically go back and grab the disc from 7 years ago, or you can grab the latest disc and go back to any point in time in the last 7 years.
That way, if a single piece of optical media fails or goes missing, you can simply grab any piece of optical media that contains the history that you want.
You need to segregate your passwords into a few buckets:
- The OMG I'm screwed bucket. Things like your financial passwords, administration account and primary email account passwords. Those should be memorable, complex (mix of upper/lower/numbers at a minimum), as long as reasonably possible (at least 10-12 chars, 15-18 would be better). Don't ever reuse one of those elsewhere. If you save them to a file, use a text file where you have pasted in a GPG encryption ASCII encoded block. Never save them in plain text. Keep a copy in a sealed envelope in your safe deposit box or personal safe. Don't let the browser remember them. (In general, you can probably remember most of these with a bit of effort as there's only a small handful of passwords that fall into this category.)
- The ones that would let someone impersonate you, in a place that matters such as a public event or in business. This includes anything that is tied to a payment method. For these, you want to go random (shell script, rolling dice, whatever) and go long (15-30 characters) with mixed-case, numbers and symbols. Every site should have a unique password, with no reuse between sites. It doesn't matter much if you use Keypass or Mozilla's password safe or GPG to store them, as long as you secure that storage with a long passphrase. I suggest keeping a backup of those passwords in a text file protected with GPG (one file per account/site).
- The sites that just don't matter. Most forums or any website where you aren't tying a payment method to the account. Generate a random password and let the browser remember it. A password reset is only a click away and if someone does hack the site and get your password (or its hash), all they have is a long string of gibberish that isn't used anywhere else.
(Note the common theme, don't reuse passwords.)
It isn't just laziness. It's also money. It is difficult to get a balanced diet on a low budget. (Not impossible, but difficult.)
That's an education issue and not a problem of what is sold at the grocer. Stick to things like rice, potatoes and pasta as a base, add in fresh or frozen vegetables, along with beans/lentils. Keep a basic spice rack. Stay away from the frozen meals, most things in a can, sodas, snack foods and other high-calorie low-nutrition junk.
Learn to cook dishes from scratch. Stay away from (most) fast food. The main downside is that you need to spend more time prepping and cooking each day rather then just popping something in a microwave.
But they more than made up that loss on games sales. Consoles are traditionally sold at a loss.
And they were trying to get 30% of the take from Windows RT application sales. So they should have done it the same as the XBox rollout. Sell the hardware at a loss and build enough of a market so that developers are willing to participate int he Windows RT application store.
And they all flopped and were discontinued. Largely because of lack of compatibility with x86 Windows; you could run some x86 programs (slowly) on the non-x86 builds, but then why not just buy an x86 machine in the first place?
Which was the absolute genius of the early AMD Opteron and AMD64 processors. You could get great performance for your 32bit x86 applications, while running on a CPU that was capable of 64bit.
And they ate Intel's lunch for a while in the server-side where companies wanted to start moving towards 64bit capable hardware and off of 32bit. If you were buying server hardware c2006, your choice was a 32bit Intel CPU or a 64bit AMD CPU. Intel wanted you to use Itanium for your 64bit stuff, companies said "screw that" and installed Opteron 64bit CPUs instead.
As a result, as we moved from 32 bit XP to 64bit Win7, we didn't have to swap out the hardware. For machines built in 2006-2008 time-frame. We just put in a bit more RAM and a SSD drive and they're good to go for a few more years.