There's a big difference between "books that you consume" and "books that you reference".
The former category in things like fiction or biographies or anything that you read sequentially from start to finish work very well in electronic form. With the advantage that you can carry around weeks worth of books without all the bulk and heft of paper copies. The better of the early readers that used the e-ink screens would get battery life measured in weeks, not hours. This meant that you could charge them up at the start of the month, leave it on the nightstand by your bed, and be sure of a few weeks of reading pleasure at bedtime before you would have to go looking for a cord.
Their downside was the speed of the e-ink. It was fast enough for sequential page turning, but that was about it.
The second category of reference works is a whole different kettle of fish. You need search (which means keyboard input of some sort) along with fast bookmarking, highlighting, linking between topics, etc. That's much harder to pull off. I greatly prefer paper copies for reference works like programming documentation or books that teach specific technologies (Spring, MVC, Java, JavaScript, CSS) where I can mark them up, highlight sections, attach bookmarks to pages, etc.
I forgot the code names, but the first Itanium was Intel designed. Had really bad performance, landed with a thud. HP (back when they had engineers and not marketers) designed the second set, which actually was a decent chip. HP had a lot vested in this, HP slowly moving away from Itanium is very very big.
Itanium floundered and failed for a few reasons, but the top one was:
A 64bit chip that gave horrible 32bit performance. Whereas AMD offered up their Athlon64 / Opterons which were 64bit capable *and* ran 32bit applications as fast or faster then the previous chips.
So, when you are faced with upgrading to new servers, you know you want to go 64bit at some point, but you're not ready to make the jump just yet... do you go with the Itanium (expensive, poor performance) or the Athlon64/Opteron which runs all your current applications very well and is also 64bit future-proofed.
While Intel tried to push everyone to 64bit Itanium land, the users decided to hedge their bets and go with AMD64 solutions.
Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.
So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.
One key to rule them all and in the darkness bind them.
In general if the encryption key is not compromised, then encryption provides much more security than pure hashing, or even hashing with a salt.
Horseshit.
If all of your passwords are encrypted with a single key, a single leak of that key exposes all 38 million accounts. You can wish upon a star all you want that the key won't be compromised, but if it is (all keys leak) you are utterly and totally screwed.
With one-way hashes and per-user salts, there is no single weakness that exposes all 38 million accounts. The attacker has to do at least some grunt-work against each account in order to crack a single user's password. If you enforce even modest password length, complexity and check against known passwords on your users, you've just driven up the attacker's costs by a few orders of magnitude.
I agree that e-mailing a password is poor practice. But how is e-mailing a 10-digit code for a self-service password reset any better? The adversary can intercept that just as easily.
The better systems treat that 10-digit code as a time-limited authentication token. So if you don't use it within say 24h, it expires and can't be used to reset the password.
If you send the new password to the user, it gets stored in their email folders and will be available down the road for an attacker to use when they stumble across it.
Salting with a random 16+ bit value that is unique per user is still (and will always be) a required step in password storage. Just because it doesn't help you against GPU accelerated attackers does not mean that it still doesn't have value.
It prevents the use of rainbow table attacks and it prevents the case where breaking one password exposes other accounts that were using the same password.
The issue of people picking passwords that exist in the top 100 lists is a whole different issue. Mostly due to password forms not requiring at least a moderate amount of complexity combined with not enforcing a minimum length. These days, if you're not forcing users to pick at least 10 character passwords and allowing entry of up to 100+ then you are doing it wrong. I'd even say you should force them to include at least one letter of the other case plus at least one number and/or symbol. Then check their password against a top-10000 database before allowing it.
The GPU acceleration issue can be tackled by switching to a hash that takes longer to calculate, then bumping up the cycle count by 1000 or 10k. And make sure that your password storage allows you to change that cycle count down the road.
I would think you could easily discover corruption in BTRFS since it has checksums.
And if you're going to complain about that, then you should use rdiff-backup over just rsync w/ links because rdiff-backup stores a checksum (SHA1, I think) along with the file data.
There's also switches to force rsync / rdiff-backup to examine the entire file instead of just the size and mtime.
I prefer to rdiff-backup to a local directory, snapshot (LVM), mount it as read-only, then rsync the rdiff-backup to the remote host. The read-only snapshot ensures that things don't change while rsync is working.
This gives me a few advantages over just plain rsync:
- The diffs are stored in compressed format. If a 100MB file changes, the diff is often only 1-5MB.
- rdiff-backup has built-in command for aging out old backups, so its easy to backup nighty and keep 27 weeks or so.
- Checksums of all files, which you can have rdiff-backup verify.
- File system metadata (ownership/permissions) are stored in metadata files, so it doesn't matter what the target file system is.
- Very friendly to rsync.
We use the same rdiff-backup target directories to write (rsync) to LUKS encrypted USB drives that get hooked up each day. With a udev rule and a keyfile for unlocking the drive, you can make that process automatic as well.
Network speed was identified as a problem by the questioner. With a neighbour, perhaps on the opposite site of the street where a fire is unlikely to spread, a fast wifi link could be used.
If you use the right backup software -- something that is rsync-friendly (rdiff-backup is a good candidate), you only need to do a bulk-copy at the start, then the nightly changes are likely to only be 1-3 GB in size (if even that much). For a home office user who isn't do media (images/videos), they might only need to backup a few hundred MB per night.
Even at old T1 speeds (1.5Mbps bi-directional), you can move 500 MB/hr in each direction.
Seriously, if bandwidth limitations are a primary issue, then you need to tackle that by using a backup tool which is easy to sync over the low-bandwidth connection.
hell you can burn-in a CRT if you try. nobody ever complained about that being a downfall of the technology.
We didn't have many other options back then... so yes, we complained about it (and it was a big problem back in the 80s/90s), but it wasn't the primary downfall.
Weight (which limited screen size) + power consumption (also put limits on screen size) + the bulk of the screen is what killed CRTs.
I can pickup a 24-27" LED display for my desk for under $300. My old 19" CRT cost something like $500-$600 at the cheapest. Plus it weighed in at 70-80lbs and consumed 120-150W of power. And used up a ton of desk space.
Well, definitely true about CCFLs... not so sure it's true about the LEDs. Are there hard numbers for this yet?
Plus, the LED backlights are so bright that you'll probably start with the brightness at 25-30% to start with lots of room to increase it as the panel ages -- if that's an issue.
NHC did a poor job of communicating, which led to city officials like Bloomberg playing down the storm as close as 48h prior to landfall. The problem was that Sandy didn't fit the classic definition of a hurricane, even though we had 75-80kt winds over a few hundred mile wide path. So while everyone is running around saying "it's not a hurricane", it still packed those 75-80kt winds and had a very large storm surge.
We were without power for about 7 days on Long Island, and it took close to three weeks for gas lines to subside. Even with filling up my tank a day or two prior to the storm, I was having trouble getting gas 10 days later.
Fortunately, we still had water & gas at home, so cooking / bathing was not an issue.
Like much in the linux world these days, systemd was rushed into production before it was half completed by too many distros.
Smart money is to either wait for it to hit Debian Stable or for it to be released by RHEL into an actual release of their server product (and not just has a "technology preview").
At the earliest, I would guess RHEL 7. Since that is going to be based on Fedora Core 19, which included systemd, it's a pretty good guess.
Of course, we have yet to see RHEL7 officially announced and RHEL6 is already 3-years old. It usually takes them about a year after announcing which FC they're basing the next release on, so I'm guessing Spring/Summer 2014 for RHEL7.
One of the fundamental problems with spam is that email is amazingly easy to fake. I can send you an email from president@whitehouse.gov through any valid SMTP server and it will arrive as such. What my proposal does is verifies the claimed key or signature is the correct key for the claimed source account.
Go look at DKIM and SPF (and not SenderID). The problems have been discussed ad nauseam and those are the best solutions to date. And even they have a lot of fun and unworkable corner cases.
Frankly, it's the responsibility of the domain owner for "whitehouse.gov" to publish SPF records that says "only trust emails coming from these locations, trash all others as forgeries".
(Yes, SPF breaks forwarders, but I consider forwarders to be part of the problem area of SMTP and they need to change to some other setup.)
Eh, the text-only ship has sailed and sunk. I'm not one to argue that having a full blown web browser is a good thing in a mail client, but there's a lot to be said for allowing embedded images, mark-up, and more things then just plain text with *bold* and _italic_ and quoting.
For instance, if I want to help a user over email and tell them how to set some obscure setting in a program's GUI, I can either type out 100-200 words explaining how to get to the item and what to set it to. Or I can trim that down and just embed an image of the setting along with highlighting portions of the image.
And a good mail client allows you to block remotely loaded content by default, then whitelist specific senders / domains.
Until just a very few years ago (around the time of CMCA), in order to enforce a copyright you had to DECLARE it. That means publicly declare who the copyright belongs to, and when the work was produced.
That hasn't been true in the USA since the 90s. Possibly earlier.
Eh, our T1 goes out maybe once per year, and has a SLA.
Our cable network drops 2-3x per month and we have no better options. But it's about 30-35Mbps inbound and 3-5Mbps outbound, so far better bandwidth then the T1.
So we use both. The T1 is the fallback line for the cable internet and traffic automatically shifts from the cable line to the T1. It might take 2-3 minutes for the shift to happen, but its automatic and is better then a 30-240 minute downtime.
Bullshit. The vast majority of drive-by browser infections these days come from either hacked sites or ad-networks that serve up malware in an ad (usually JavaScript or Flash, but sometimes Java plug-in).
Case-in-point. I have a user who would get infected monthly, just from doing research on the web using Internet Explorer on WinXP. Not visiting dodgy sites, but doing regular business research on companies / products / etc.
Finally got tired of cleaning/wiping the machine monthly so we installed Firefox + FlashBlock + NoScript. Problem went away and no further infections have occurred (even as other machines in the office got infected). Because the JavaScript / Flash objects don't run unless they are white-listed, they can't be used to infect the machine just because it loaded an ad object.
You need the boost as soon as you try to do two (or three) things at the same time, which all hit the hard drive for more then a few MB of data. Which for people who never learned to multi-task or treat the computer as a consumption device, it probably doesn't matter.
For the rest of us (developers, system administrators, content creators) SSD speed helps out immensely.
Yeah, internal users who only exchange documents with other internal users are a solved problem (either use Libre/Open Office for everything, or wikis, or some other document management system).
The thorny bit is when dealing with external customers... who use Microsoft Office XYZ. Any glitches in that exchange means lost business, and sending PDFs back and forth is not always acceptable either.
So, we're stuck using what our client use. With a few people trying out LibreOffice for internal only stuff.
Slashdot Mirror
There's a big difference between "books that you consume" and "books that you reference".
The former category in things like fiction or biographies or anything that you read sequentially from start to finish work very well in electronic form. With the advantage that you can carry around weeks worth of books without all the bulk and heft of paper copies. The better of the early readers that used the e-ink screens would get battery life measured in weeks, not hours. This meant that you could charge them up at the start of the month, leave it on the nightstand by your bed, and be sure of a few weeks of reading pleasure at bedtime before you would have to go looking for a cord.
Their downside was the speed of the e-ink. It was fast enough for sequential page turning, but that was about it.
The second category of reference works is a whole different kettle of fish. You need search (which means keyboard input of some sort) along with fast bookmarking, highlighting, linking between topics, etc. That's much harder to pull off. I greatly prefer paper copies for reference works like programming documentation or books that teach specific technologies (Spring, MVC, Java, JavaScript, CSS) where I can mark them up, highlight sections, attach bookmarks to pages, etc.
(shrugs) I'm still running a Thinkpad T61p from 2007. It now has 8GB RAM, Win7 Pro and a pair of SSDs after upgrades last year.
Unless something goes horribly wrong with it, I'll probably use it until 2014-2015.
(Thinkpads come with 4y or 5y warranties as an option.)
Still looks like arse and when you go to read the comments, they're packed into the middle third of the screen.
heavy metal vocalist screaming a language you don't know through a couple of tin cans and a piece of string, from underwater...
Stop spying on my music listening habits!
I forgot the code names, but the first Itanium was Intel designed. Had really bad performance, landed with a thud. HP (back when they had engineers and not marketers) designed the second set, which actually was a decent chip. HP had a lot vested in this, HP slowly moving away from Itanium is very very big.
Itanium floundered and failed for a few reasons, but the top one was:
A 64bit chip that gave horrible 32bit performance. Whereas AMD offered up their Athlon64 / Opterons which were 64bit capable *and* ran 32bit applications as fast or faster then the previous chips.
So, when you are faced with upgrading to new servers, you know you want to go 64bit at some point, but you're not ready to make the jump just yet... do you go with the Itanium (expensive, poor performance) or the Athlon64/Opteron which runs all your current applications very well and is also 64bit future-proofed.
While Intel tried to push everyone to 64bit Itanium land, the users decided to hedge their bets and go with AMD64 solutions.
Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.
So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.
One key to rule them all and in the darkness bind them.
In general if the encryption key is not compromised, then encryption provides much more security than pure hashing, or even hashing with a salt.
Horseshit.
If all of your passwords are encrypted with a single key, a single leak of that key exposes all 38 million accounts. You can wish upon a star all you want that the key won't be compromised, but if it is (all keys leak) you are utterly and totally screwed.
With one-way hashes and per-user salts, there is no single weakness that exposes all 38 million accounts. The attacker has to do at least some grunt-work against each account in order to crack a single user's password. If you enforce even modest password length, complexity and check against known passwords on your users, you've just driven up the attacker's costs by a few orders of magnitude.
I agree that e-mailing a password is poor practice. But how is e-mailing a 10-digit code for a self-service password reset any better? The adversary can intercept that just as easily.
The better systems treat that 10-digit code as a time-limited authentication token. So if you don't use it within say 24h, it expires and can't be used to reset the password.
If you send the new password to the user, it gets stored in their email folders and will be available down the road for an attacker to use when they stumble across it.
Salting with a random 16+ bit value that is unique per user is still (and will always be) a required step in password storage. Just because it doesn't help you against GPU accelerated attackers does not mean that it still doesn't have value.
It prevents the use of rainbow table attacks and it prevents the case where breaking one password exposes other accounts that were using the same password.
The issue of people picking passwords that exist in the top 100 lists is a whole different issue. Mostly due to password forms not requiring at least a moderate amount of complexity combined with not enforcing a minimum length. These days, if you're not forcing users to pick at least 10 character passwords and allowing entry of up to 100+ then you are doing it wrong. I'd even say you should force them to include at least one letter of the other case plus at least one number and/or symbol. Then check their password against a top-10000 database before allowing it.
The GPU acceleration issue can be tackled by switching to a hash that takes longer to calculate, then bumping up the cycle count by 1000 or 10k. And make sure that your password storage allows you to change that cycle count down the road.
before WhatsApp became the new BBM
That's funny... WhatsApp is one of the primary spammers to fill my mailbox each day.
I would think you could easily discover corruption in BTRFS since it has checksums.
And if you're going to complain about that, then you should use rdiff-backup over just rsync w/ links because rdiff-backup stores a checksum (SHA1, I think) along with the file data.
There's also switches to force rsync / rdiff-backup to examine the entire file instead of just the size and mtime.
I prefer to rdiff-backup to a local directory, snapshot (LVM), mount it as read-only, then rsync the rdiff-backup to the remote host. The read-only snapshot ensures that things don't change while rsync is working.
This gives me a few advantages over just plain rsync:
- The diffs are stored in compressed format. If a 100MB file changes, the diff is often only 1-5MB.
- rdiff-backup has built-in command for aging out old backups, so its easy to backup nighty and keep 27 weeks or so.
- Checksums of all files, which you can have rdiff-backup verify.
- File system metadata (ownership/permissions) are stored in metadata files, so it doesn't matter what the target file system is.
- Very friendly to rsync.
We use the same rdiff-backup target directories to write (rsync) to LUKS encrypted USB drives that get hooked up each day. With a udev rule and a keyfile for unlocking the drive, you can make that process automatic as well.
Network speed was identified as a problem by the questioner. With a neighbour, perhaps on the opposite site of the street where a fire is unlikely to spread, a fast wifi link could be used.
If you use the right backup software -- something that is rsync-friendly (rdiff-backup is a good candidate), you only need to do a bulk-copy at the start, then the nightly changes are likely to only be 1-3 GB in size (if even that much). For a home office user who isn't do media (images/videos), they might only need to backup a few hundred MB per night.
Even at old T1 speeds (1.5Mbps bi-directional), you can move 500 MB/hr in each direction.
Seriously, if bandwidth limitations are a primary issue, then you need to tackle that by using a backup tool which is easy to sync over the low-bandwidth connection.
hell you can burn-in a CRT if you try. nobody ever complained about that being a downfall of the technology.
We didn't have many other options back then... so yes, we complained about it (and it was a big problem back in the 80s/90s), but it wasn't the primary downfall.
Weight (which limited screen size) + power consumption (also put limits on screen size) + the bulk of the screen is what killed CRTs.
I can pickup a 24-27" LED display for my desk for under $300. My old 19" CRT cost something like $500-$600 at the cheapest. Plus it weighed in at 70-80lbs and consumed 120-150W of power. And used up a ton of desk space.
Well, definitely true about CCFLs... not so sure it's true about the LEDs. Are there hard numbers for this yet?
Plus, the LED backlights are so bright that you'll probably start with the brightness at 25-30% to start with lots of room to increase it as the panel ages -- if that's an issue.
NHC did a poor job of communicating, which led to city officials like Bloomberg playing down the storm as close as 48h prior to landfall. The problem was that Sandy didn't fit the classic definition of a hurricane, even though we had 75-80kt winds over a few hundred mile wide path. So while everyone is running around saying "it's not a hurricane", it still packed those 75-80kt winds and had a very large storm surge.
We were without power for about 7 days on Long Island, and it took close to three weeks for gas lines to subside. Even with filling up my tank a day or two prior to the storm, I was having trouble getting gas 10 days later.
Fortunately, we still had water & gas at home, so cooking / bathing was not an issue.
Like much in the linux world these days, systemd was rushed into production before it was half completed by too many distros.
Smart money is to either wait for it to hit Debian Stable or for it to be released by RHEL into an actual release of their server product (and not just has a "technology preview").
At the earliest, I would guess RHEL 7. Since that is going to be based on Fedora Core 19, which included systemd, it's a pretty good guess.
Of course, we have yet to see RHEL7 officially announced and RHEL6 is already 3-years old. It usually takes them about a year after announcing which FC they're basing the next release on, so I'm guessing Spring/Summer 2014 for RHEL7.
One of the fundamental problems with spam is that email is amazingly easy to fake. I can send you an email from president@whitehouse.gov through any valid SMTP server and it will arrive as such. What my proposal does is verifies the claimed key or signature is the correct key for the claimed source account.
Go look at DKIM and SPF (and not SenderID). The problems have been discussed ad nauseam and those are the best solutions to date. And even they have a lot of fun and unworkable corner cases.
Frankly, it's the responsibility of the domain owner for "whitehouse.gov" to publish SPF records that says "only trust emails coming from these locations, trash all others as forgeries".
(Yes, SPF breaks forwarders, but I consider forwarders to be part of the problem area of SMTP and they need to change to some other setup.)
Eh, the text-only ship has sailed and sunk. I'm not one to argue that having a full blown web browser is a good thing in a mail client, but there's a lot to be said for allowing embedded images, mark-up, and more things then just plain text with *bold* and _italic_ and quoting.
For instance, if I want to help a user over email and tell them how to set some obscure setting in a program's GUI, I can either type out 100-200 words explaining how to get to the item and what to set it to. Or I can trim that down and just embed an image of the setting along with highlighting portions of the image.
And a good mail client allows you to block remotely loaded content by default, then whitelist specific senders / domains.
Until just a very few years ago (around the time of CMCA), in order to enforce a copyright you had to DECLARE it. That means publicly declare who the copyright belongs to, and when the work was produced.
That hasn't been true in the USA since the 90s. Possibly earlier.
Eh, our T1 goes out maybe once per year, and has a SLA.
Our cable network drops 2-3x per month and we have no better options. But it's about 30-35Mbps inbound and 3-5Mbps outbound, so far better bandwidth then the T1.
So we use both. The T1 is the fallback line for the cable internet and traffic automatically shifts from the cable line to the T1. It might take 2-3 minutes for the shift to happen, but its automatic and is better then a 30-240 minute downtime.
Bullshit. The vast majority of drive-by browser infections these days come from either hacked sites or ad-networks that serve up malware in an ad (usually JavaScript or Flash, but sometimes Java plug-in).
Case-in-point. I have a user who would get infected monthly, just from doing research on the web using Internet Explorer on WinXP. Not visiting dodgy sites, but doing regular business research on companies / products / etc.
Finally got tired of cleaning/wiping the machine monthly so we installed Firefox + FlashBlock + NoScript. Problem went away and no further infections have occurred (even as other machines in the office got infected). Because the JavaScript / Flash objects don't run unless they are white-listed, they can't be used to infect the machine just because it loaded an ad object.
You need the boost as soon as you try to do two (or three) things at the same time, which all hit the hard drive for more then a few MB of data. Which for people who never learned to multi-task or treat the computer as a consumption device, it probably doesn't matter.
For the rest of us (developers, system administrators, content creators) SSD speed helps out immensely.
Yeah, internal users who only exchange documents with other internal users are a solved problem (either use Libre/Open Office for everything, or wikis, or some other document management system).
The thorny bit is when dealing with external customers... who use Microsoft Office XYZ. Any glitches in that exchange means lost business, and sending PDFs back and forth is not always acceptable either.
So, we're stuck using what our client use. With a few people trying out LibreOffice for internal only stuff.
Try either FreeNX/NX or X2GO for the equivalent of RDP.