Depends on what you mean for a budget system. Dual-core does give you a slight performance improvement over single-core, even for single-threaded games because the miscellaneous tasks can be shunted to the 2nd core allowing your game to use 100% of a core rather then just 95%.
Which would have reasonable performance, good expandability. The basic Athlon64 CPUs are ~$90. Add on case ($80), power-supply ($60), hard drive ($80), DVD-writer ($40), Gfx card ($150), and WinXP license ($135) and you should be up around $800 for a decent budget system with good upgrade potential.
Add on the $545 in miscellaneous parts for a total price of $1160. Which would be a more powerful machine for a still somewhat reasonable price.
The big advantage of DIY is that you can move a lot of the miscellanous parts from one system to another as you upgrade. So you might save $200 because you're not re-buying things like hard drives, GFX cards, DVD-ROM drives, cases, power-supplies.
You failed to mention the amount of memory on the systems.
I'm a firm believer in the more memory the merrier. Looking around the home office, I have machines with anything from 1GB (laptop) to 3GB (my video editing box). Swapping to the hard drive is *slow*. Sure, it made sense back when systems were slower and RAM was super-expensive, but today it's something that should be avoided.
I'd rather have a 20% slower CPU and twice the RAM for the same cost. Which is something I always tell prospective buyers. Bump the CPU speed down 1 notch and double the amount of RAM with the cost savings.
In general, if you don't know the person on the other side of the connection you should assume that they're up to no good and are not who they say they are. And even if I know the person on the other side, I don't automatically assume that they are who the screen says. I keep an eye out for non-standard speech or someone that suddenly starts asking for sensitive information who normally doesn't.
I'm not sure how one would go about teaching that. Except by teaching your children not to believe everything that a stranger tells them. There's an "art" in being able to tell truth from lies when dealing with a stranger in a face-to-face meeting. It's harder in a faceless medium such as e-mail or IM (or even phones).
Maybe the old adage, "if it sounds too good to be true it probably is" applies.
Or the cliched story about the guy who gets all worked up over some hot chick in a chat room only to find out he's made a date with an overweight, grizzled, 50+ year old male. (Probably not suitable as a teaching story for most children.)
My advice to you is keep it simple and more secure by not implement IM at all. Tell you user base to let their fingers and/feet do the walking. The exercise is good for people sitting for most of the day anyway.
That's very short-sighted of you.
IM works well for cutting down on the number of internal calls, which is very good when you have remote workers. Most people find it to be less intrusive then a telephone call (I can do multiple things while monitoring a chat conversation). It works well for those quick questions or for communicating information which is tricky to read over the phone.
That doesn't mean that it supplants / replaces telephone calls. My co-worker and I (who are a few hours apart) regularly flip between using e/pop and a telephone call depending on what needs to be discussed. Often, we'll be on the phone talking to each other and pop up an e/pop chat window to exchange URLs or technical details. Which means neither of us have to spend 3 minutes trying to read out a URL.
Or if one of us is on the phone, we can e/pop another person to find out their input on something. Or get a question answered without leaving a voice message and playing phone tag.
Getting effective use out of an IM solution is an education issue. Just like e-mail, you need to train your users when and why to use IM instead of phone instead of e-mail. Telephones excel for in-depth conversations because of the verbal cues (face-to-face is still better, but not always possible) but IM excels for detail conversations (where you need to exchange part #s, URLs, or other text information). E-Mail is a time-shifted medium. All of them are "tools" for communication and each is useful in different situations.
One example of a training issue with IM: A polite IM conversation begins with "hello" and ends when *both* parties say "goodbye". A few of our users were very "abrupt" when using IM. They'd leave the chat room as soon as they thought their question was answered, which is a bit like slamming down the telephone receiver in real life. We've had to train them to wait for a "goodbye" signal from the other side so that they don't appear so rude.
Also, we found that without an IM solution in-house, our users were attempting to use e-mail as a instant message system. They would complain about not getting e-mail back from someone within 5 minutes. The IM solution defuses that situation by giving them a more instant-feedback communication avenue. (And I can go back to telling users not to check e-mail more often then twice an hour.)
This was used to be a fairly good product (e/pop Professional). It offered encrypted communications, tied into various directory schemes *and* offered you a built-in remote control facility so that you could see the user's screen. That was invaluable for support staff as they could see what the user was trying to do and help them out directly. It was also fairly robust (although there were bugs when e/pop had to deal with multi-homed machines such as remote workers who VPN'd in).
Unforunately, WiredRed no longer makes the e/pop Professional client. Instead, you have to buy the Web Conferencing package in order to get remote control abilities. (At least, if I read the website verbiage correctly.) And the basic chat client is now just e/pop Basic. Both require a minimum purchase in the range of a few thousand dollars (minimum purchase is 100 clients) with an annual maintenance fee that is 20% of the purchase price.
It's a real pity. They had a very good product that I was willing to recommend to small businesses (50 employees). Now we're evaluating Jabber (WildFire server + Spark clients) and we'll investigate using VNC for the remote control side.
Most people have responded with their experiences in keeping track of their passwords, but I was wondering if it would be possible to implement a system where the password expiry would be based on the complexity of your password.
And as an attacker, if I could find out this information (knowing which accounts expire frequently), that would tell me which accounts to attack (due to having less complex passwords). Not outside the realm of possibility, however unlikely, and it provides information on the password.
(A similar concept is the old Lotus Notes login screen. Instead of displaying a single '*' for each character typed, it would display a random number of '*'s. That made it more difficult for a shoulder surfer to see how many characters were in the passphrase at a glance. Note: It was still possible to listen to the keyboard or, worse, watch the operator's hands or shoulder movements.)
It's an Opteron 246 chip (well, actually a pair of them, but TrueCrypt 4.2 isn't multi-threaded yet) from around early 2005. I know it wasn't top of the line when I bought it (I think the 248s were out by then).
It's the 2GHz core with 3GB of PC3200 RAM running WinXP Pro 32bit. The motherboard is a Tyan Tiger K8W S2875 with a slightly odd memory path. Only one of the Opterons is connected to the memory, the 2nd Opteron routes its memory access through the first one. It's not ideal, but it was the smallest form factor dual-CPU motherboard I could find at the time. (The newer K8WE S2877 has separate memory banks for each CPU.)
At some point I'll upgrade to the S2877 board with a pair of dual-core Opterons. Probably the 280s (2.4GHz) once they get below the $250-$300 mark.
I use GPG as well, but I keep each password in a separate text file. That way, even if someone shoulder-surfs me, they can only see a single password.
Most passwords that I use are randomly generated using a custom script that I wrote (a dictionary of 300k words combined with numbers, caps and symbols).
Look into using a password safe or keeping seldom-used password / account information in GPG-encrypted text files. That way you only have to remember a core password / passphrase to get at seldom-used secrets.
For the GPG method, create a new text file for each resource. Open it up in notepad, type in the access information. Then copy the contents to the clipboard and encrypt it before pasting it back into the text file. Now you have a secure secret that you can put anywhere (shared folder, mailed to your home or webmail account, or printed out and left on a desk). Plus it's easy to backup.
If / when you need access to that secret again, open up the text file and decrypt the contents.
1) The ones I deal with on a daily basis. These number in the range of about 1 dozen, but are still easily rememberable. Length varies from 12-30 characters, includes digits, mixed-case and is comprised of multiple words. Memorable, typeable, and fairly secure. Some of the longer ones are 40-80 characters in length, but they are ones that I only use when booting up the laptop every few weeks. I use them all frequently enough that they're memorable (although I still back them up in a GPG-protected file).
2) The ones that I let the web browser remember. Such as forum passwords. Since I use a laptop that I keep secure, I'm not terribly worried about letting the web browser remember these. Those passwords are generated by a random algorithm and are usually 20-40 characters in length with random caps and symbols inserted into the middle / ends / beginning. I keep track of these by placing them in a text file prior to encrypting to contents of the text file with my GPG key. If I ever need to look them up, I open the text file, copy the contents to the clipboard and decrypt it.
3) Other seldom used passwords. These are almost all randomly generated (30+ characters with random sybols, digits and caps). Again, I simply store them in plain text files where the contents of the file is a GPG encryption block. To get at the password, I copy the contents into the clipboard, decrypt and there I have it.
The plain text file with GPG encrypted contents works well for many reasons. It's backup-friendly (I could even put the contents into source code control), I can e-mail the blocks to myself on other machines without worries or I can make backups of all of my passwords by mailing them to a webmail account. I can setup the contents of the file to be readable by my co-workers for cases where multiple of us need access to the password.
Sounds like your company is about the size of ours (less then 50 employees). We have a variety of backup schemes, depending on the user.
For our remote workers using laptops, version-control software for corporate data and staying in sync with the other workers in their department. Combined with SecondCopy + TrueCrypt partitions on the USB/FireWire drives. The local USB/FW drive handles things like backing up their personal files or e-mail. We also recommend that they make use of a tool like Acronis TrueImage / Knoppix+NTFSClone / Ghost to make snapshots of their system. TrueCrypt works well as a backup target in this scenario because SecondCopy is a user-space tool rather then a background service.
For the corporate server backups, we run a two-stage system. We have an onsite server that is large enough to hold 2 weeks of backups on disk. This server is always available so there's no worries about drives not being ready. The primary backup runs at night during off-peak times. Then, during the day, we use a workstation to copy data from the backup machine to removable hard drives.
I'm experimenting with using TrueCrypt on those removable hard drives. The secondary backup workstation is always up and running (with a user logged in) to perform other tasks, so it should not be difficult for us to keep the TrueCrypt volume mounted. Or I could use the command-line features of TrueCrypt to automatically mount/dismount the volume. But I'll probably simply opt for leaving the drive mounted until it's time to remove it. (The removable drives are PATAs installed in StarTech DRW115 series bays/trays.)
We take our backup drives offsite weekly (with a current rotation of 6 drives, slowly expanding to 12 drives). Tape was too finicky for us. I had originally considered encrypting the target data using a GPG public-key as it was copied to the drive, but that is slow and tedious for recovery. EFS was a non-starter due to the portability issues, but TrueCrypt looks like it has the right level of security combined with ease of use.
Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.
BTW, TrueCrypt includes a little benchmark tool to allow you to calculate throughput rates for the various algorithms (as implemented inside of TrueCrypt). Useful for seeing just what the best-case rates are for a particular CPU. On the Opteron 246, they stack up as:
The submitter's question linked to truecrypt as one of two programs he's tried and found not fast enough. I hear it's real nice, but he's already found it too slow for his needs.
I'm also amused by the submitter's "too slow" comment for TrueCrypt. I use it on my 4-year old laptop (a 1.7Ghz Pentium 4 mobile) and find that it's the hard drive that is the bottleneck rather then the CPU. I'm using the stock TrueCrypt settings for encryption algorithm (256bit AES, LRW mode) and hash (RIPEMD-160). I have two volumes on the laptop, one is a ~700MB TrueCrypt file volume used for extra sensitive data and the second is a full-disk encrypted FireWire drive attached to the unit (160GB).
Copying from the laptop's hard drive to the encrypted external FireWire drive gives me transfer rates of around 10-12MB/sec and uses up around 30% of my CPU. Which is not too shabby for a 4 year old laptop. I would hardly call it "too slow".
I just did the benchmarks for a 100MB buffer, the left number is speeds on my 1.7Ghz Pentium 4 mobile laptop CPU, on the right is performance of a 2Ghz Opteron 246 chip (TrueCrypt 4.2 is not multi-threaded so it only used one of the two chips installed in that system):
Those are not scientificially rigorous tests, but the built-in benchmark tool shows that the laptop's P4 is capable of very high encrypt/decrypt rates. It also looks like Serpent/CAST5 algorithms possibly don't fit inside the CPU cache very well (the Opteron chip has a larger L2 cache) or Serpent/CAST5 use operations that are more efficient on the Opteron chip. I don't know enough about the individual characteristics to make more educated guessed then that.
It's a pity that TrueCrypt isn't multi-threaded, or the dual-CPU Opteron system would've scored even higher on the TrueCrypt benchmark. I've run the benchmarks for a few different sizes (10MB / 50MB / 100MB / 500MB) and the numbers all tend to add up the same way (within a few percentage points) across the board.
The big problem with NTFS encryption (a.k.a. Windows EFS) is that:
- The keys are tied to the machine (you can't take those USB drives and mount them on another machine, at least not when I tested it)
- The keys are a PITA to backup, the management interface is clunky
- It's not the strongest system in the world (I believe there are numerous issues with how it was implemented)
That being said, it's generally better then nothing for when you want to protect semi-confidential data. Most attackers won't take the time to break it.
But for external USB backup drives, I strongly recommend you consider switching to something like TrueCrypt. Just create a partition, don't format it or assign it a drive label, then let TrueCrypt create a 'device' volume on the partition. You'll be assured of being able to take it from machine to machine with no worries as long as you know the passphrase and/or have the keyfiles for the volume. Works very well for laptop-centric backups using tools like SecondCopy where your target volume is the encrypted USB/FireWire drive.
If the crypto is done right, shouldn't destroying the keys and maybe some random parts of the file be enough to completely remove any hope of recovering the data?
If I understand TrueCrypt's technology and assuming that you didn't let an attacker copy your TrueCrypt volume header... overwriting the first 512 bytes of a TrueCrypt volume destroys the key for that volume. Unless you have a backup of the volume header, your data is lost and unrecoverable unless you get lucky and can break the encryption key.
So it's (theoretically) a lot faster to destroy the contents (or at least make them inaccessible to anyone) with a encrypted volume file like TrueCrypt uses. I can't say for sure whether PGPDisk or DriveCrypt use the same sort of storage system (with the encryption keys stored at the start of the volume file).
All this new harddrive tech is cool and all, but what I want more than anything else, including more and more massive storage, is better reliability.
In the past year or so, I've had, literally, 50% of all drives I have purchased fail. Mostly Western Digitals, FWIW.
For that matter, I've had several expensive raid controllers fail too. This shit is really starting to piss me off.
Odd, because I haven't seen a drive fail in quite a while personally (and I probably have 20+ spindles sitting next to me in my office). I have a mix of Seagate, Maxtor, Hitachi and Western Digital.
As always, the #1 killer of drives is heat followed by poor power. Mechanical damage is also possible, but not likley in stationary systems.
So, what operating temps were you running at? Were you using a line-conditioning UPS to correct over/under voltage situations? Was your power supply a no-name cheap one or a quality one with good tolerances?
Because a lot of sites use smaller text for footer information. Which isn't what I consider "main" content. So if I set my minimum font size to be equal to my desired font size, it causes issues where text that should be small (8 point instead of 10-12 point) looks odd.
The core problem is that well-behaved and well-designed sites shouldn't force a font size on the user for primary content.
Agreed, I started by learning BASIC (numerous incarnations up through GW-BASIC) about 20 years ago. Then came FORTRAN, followed by Pascal, followed by C. A few years of C++, then some VBScript followed by some VB, Java, with a smattering of Perl. Oh and some REXX thrown in for good measure along with DBase III/IV and CA-Clipper.
Needless to say, new languages don't really scare me anymore. New languages shouldn't scare any experienced developer. Very rarely does a new language come up with entirely new concepts, so it's just a matter of learning the syntax and finding the various tips/tricks.
Right now, I'm trying to decide between PHP / Python / Ruby or just chucking it all and going back to Perl.
Well, for our small group of 5 developers, 4 of which are off-site 95% of the time... VSS+SOS has worked well. It probably helps that none of us are using the VSS client (instead, interfacing through SOS). Since a lot of the stuff we work with is binary files, the checkout-modify-checkin model works well.
I can't say that I've had an issue with VSS/SOS in the past 6 years. I'm well aware of its fragility and we have very very good backups. But it's treated us well. The main reason that we're looking to migrate away from VSS/SOS is licensing costs as well as cross-platform clients.
(Some companies / employees simply don't "get" the idea behind source control systems. Which is a training issue and not a technical issue. When I first introduces the VCS concept at my previous job, it took a month of evangelizing to get the developers to use it. Prior to that, they weren't using *any* VCS and VSS was vastly better then nothing.)
Have you documented your setup at all (or described the technical details) anywhere?
We're a Visual SourceSafe shop that uses SourceOffSite for our remote workers. I've been experimenting with SVN+Tortoise+SSH, but I'm finding it to be a bit slow on our test server. I know I gave up trying to setup Apache the last time that I attempted.
How are you connecting to SVN? Apache? SVNServe? SSH or SSL? Do you have offsite workers?
I run Firefox 1.5 on a 125ppi display (14" 1400x1050 LCD). My minimum font size is set to "14px". The new CSS style makes the text a bit screwy and slightly too small. My preferred font size is 18px.
The problem is that their CSS sheet specifies "14.75px" for the normal text. Which looks fine on 96ppi displays, but is horribly tiny on 125+ ppi displays. That works out to 14.75/125*72 = 8.5pt font size when my preferred size is 10pt text.
(Hint to web designers... stick with "small/normal/large/etc" tags or switch to using "pt" suffixes instead. Specifying font sizes in "px" gets you into trouble.)
I haven't decided what to do yet about Slashdot. But the readability of the site has taken a huge nosedive with the new CSS look.
Well, a few years ago it might've been necessary... it all depends on how fast your data is streaming in from your soundboard. Assuming 96kHz, 32bit, 8 channels, we get a data rate of 384KB/sec per channel or a bit over 3MB/sec for 8 channels. That's not a lot of bandwidth for modern systems.
Back when I was recording raw video (720x480, 60 interlaced frames, HuffYUV) it required a data rate of 8-9MB/sec (too lazy to go back and look for certain). Back in the 20/40GB drive days, hard drives had difficulty in writing that amount of data to the disk continuously. But with the newer 200+ GB drives, they can sustain transfer rates in the 20-40MB/sec range.
So if my 3MB/sec estimate is accurate for audio recording... that's easy for most modern hard drives to handle. Even if the drive isn't perfectly defrag'd, you shouldn't run into issues. Especially if you're recording to a dedicated spindle (i.e. a drive that is not handling other requests for data).
OTOH, if studio time is a factor, then the move/wipe/reload may be cost-effective to not have to worry about it at all.
You've apparently never seen how ugly DVD looks on a large screen.
Some of that depends on the decoder quality. Granted, I don't have a 90" screen but on my smaller 23" HDTV it's easy to see the difference on DVDs between a good/bad decoder. My cheap Sony DVD player looks horrid, even using Component output. The Samsung DVD player with upscaling looks a little better. But the best display is when I output Zoom Player Professional to my HDTV via VGA cables.
Yes, moving the data off, re-formatting, and moving the data back on is indeed a sure-fire defrag method. As the files are copied back onto the fresh volume, they automatically lay down as non-fragmented files. It's a bit stone-age now that Windows includes a built-in defrag tool (since Win2000 started shipping). (Back in the WinNT days, you had to pay extra for NTFS defrag tools.)
Modern hard drives are also less prone to bad sectors (the drive checks for these when writing and does re-mapping on the fly). For most SMART-capable drives, once you start seeing bad sectors in the output of the FORMAT command, it means that the drive has run out of rewrite sectors and is starting to fail. (I'm a bit hazy on how it all works under the covers.)
We've used Tecras since 2000 for a few reasons: 1400x1050 display, the AccuPoint / TrackPoint mouse pointer, and previous good experience with Toshibas. The Tecras seem to hold up to a decent amount of abuse (I travelled on a monthly basis in 2000-2002, usually week-long trips.).
I have a Toshiba repair depot about 25 miles away, which is convenient enough for me (it's a nice country-drive to go across the river to drop-off / pick-up). So service has never been a big issue. Typical failures are moving parts such as the CPU fan or the hard drive (which I replace myself). The warranty service has been good enough (a 5-year warranty would be welcome).
I'm not real fond of the M4 design, but the M5 looks as sturdy as my current 9100. (My objection to the M4, sight-unseen, is the swivel hinge for the screen.) We've also purchased a Thinkpad T43 in the past and that user is very pleased with it. We were considering the newer T60 as well, but we'll probably stick with Toshiba for as long as they include the high-res screens and the AccuPoint.
Slashdot Mirror
Depends on what you mean for a budget system. Dual-core does give you a slight performance improvement over single-core, even for single-threaded games because the miscellaneous tasks can be shunted to the 2nd core allowing your game to use 100% of a core rather then just 95%.
That being said, if I was building a budget level game box (using the motherboard bundles at MWave):
Athlon64 3000+ 939pin, 1GB Kingston RAM, $75 MB, Assembled = $264
Which would have reasonable performance, good expandability. The basic Athlon64 CPUs are ~$90. Add on case ($80), power-supply ($60), hard drive ($80), DVD-writer ($40), Gfx card ($150), and WinXP license ($135) and you should be up around $800 for a decent budget system with good upgrade potential.
A slightly more expensive kit would be:
Athlon64 X2 4200+, 2GB Corsair RAM, $75 motherboard, $9 assemble fee = $615
Add on the $545 in miscellaneous parts for a total price of $1160. Which would be a more powerful machine for a still somewhat reasonable price.
The big advantage of DIY is that you can move a lot of the miscellanous parts from one system to another as you upgrade. So you might save $200 because you're not re-buying things like hard drives, GFX cards, DVD-ROM drives, cases, power-supplies.
You failed to mention the amount of memory on the systems.
I'm a firm believer in the more memory the merrier. Looking around the home office, I have machines with anything from 1GB (laptop) to 3GB (my video editing box). Swapping to the hard drive is *slow*. Sure, it made sense back when systems were slower and RAM was super-expensive, but today it's something that should be avoided.
I'd rather have a 20% slower CPU and twice the RAM for the same cost. Which is something I always tell prospective buyers. Bump the CPU speed down 1 notch and double the amount of RAM with the cost savings.
In general, if you don't know the person on the other side of the connection you should assume that they're up to no good and are not who they say they are. And even if I know the person on the other side, I don't automatically assume that they are who the screen says. I keep an eye out for non-standard speech or someone that suddenly starts asking for sensitive information who normally doesn't.
I'm not sure how one would go about teaching that. Except by teaching your children not to believe everything that a stranger tells them. There's an "art" in being able to tell truth from lies when dealing with a stranger in a face-to-face meeting. It's harder in a faceless medium such as e-mail or IM (or even phones).
Maybe the old adage, "if it sounds too good to be true it probably is" applies.
Or the cliched story about the guy who gets all worked up over some hot chick in a chat room only to find out he's made a date with an overweight, grizzled, 50+ year old male. (Probably not suitable as a teaching story for most children.)
My advice to you is keep it simple and more secure by not implement IM at all. Tell you user base to let their fingers and/feet do the walking. The exercise is good for people sitting for most of the day anyway.
That's very short-sighted of you.
IM works well for cutting down on the number of internal calls, which is very good when you have remote workers. Most people find it to be less intrusive then a telephone call (I can do multiple things while monitoring a chat conversation). It works well for those quick questions or for communicating information which is tricky to read over the phone.
That doesn't mean that it supplants / replaces telephone calls. My co-worker and I (who are a few hours apart) regularly flip between using e/pop and a telephone call depending on what needs to be discussed. Often, we'll be on the phone talking to each other and pop up an e/pop chat window to exchange URLs or technical details. Which means neither of us have to spend 3 minutes trying to read out a URL.
Or if one of us is on the phone, we can e/pop another person to find out their input on something. Or get a question answered without leaving a voice message and playing phone tag.
Getting effective use out of an IM solution is an education issue. Just like e-mail, you need to train your users when and why to use IM instead of phone instead of e-mail. Telephones excel for in-depth conversations because of the verbal cues (face-to-face is still better, but not always possible) but IM excels for detail conversations (where you need to exchange part #s, URLs, or other text information). E-Mail is a time-shifted medium. All of them are "tools" for communication and each is useful in different situations.
One example of a training issue with IM: A polite IM conversation begins with "hello" and ends when *both* parties say "goodbye". A few of our users were very "abrupt" when using IM. They'd leave the chat room as soon as they thought their question was answered, which is a bit like slamming down the telephone receiver in real life. We've had to train them to wait for a "goodbye" signal from the other side so that they don't appear so rude.
Also, we found that without an IM solution in-house, our users were attempting to use e-mail as a instant message system. They would complain about not getting e-mail back from someone within 5 minutes. The IM solution defuses that situation by giving them a more instant-feedback communication avenue. (And I can go back to telling users not to check e-mail more often then twice an hour.)
I was hoping that someone would mention e/pop.
This was used to be a fairly good product (e/pop Professional). It offered encrypted communications, tied into various directory schemes *and* offered you a built-in remote control facility so that you could see the user's screen. That was invaluable for support staff as they could see what the user was trying to do and help them out directly. It was also fairly robust (although there were bugs when e/pop had to deal with multi-homed machines such as remote workers who VPN'd in).
Unforunately, WiredRed no longer makes the e/pop Professional client. Instead, you have to buy the Web Conferencing package in order to get remote control abilities. (At least, if I read the website verbiage correctly.) And the basic chat client is now just e/pop Basic. Both require a minimum purchase in the range of a few thousand dollars (minimum purchase is 100 clients) with an annual maintenance fee that is 20% of the purchase price.
It's a real pity. They had a very good product that I was willing to recommend to small businesses (50 employees). Now we're evaluating Jabber (WildFire server + Spark clients) and we'll investigate using VNC for the remote control side.
Most people have responded with their experiences in keeping track of their passwords, but I was wondering if it would be possible to implement a system where the password expiry would be based on the complexity of your password.
And as an attacker, if I could find out this information (knowing which accounts expire frequently), that would tell me which accounts to attack (due to having less complex passwords). Not outside the realm of possibility, however unlikely, and it provides information on the password.
(A similar concept is the old Lotus Notes login screen. Instead of displaying a single '*' for each character typed, it would display a random number of '*'s. That made it more difficult for a shoulder surfer to see how many characters were in the passphrase at a glance. Note: It was still possible to listen to the keyboard or, worse, watch the operator's hands or shoulder movements.)
It's an Opteron 246 chip (well, actually a pair of them, but TrueCrypt 4.2 isn't multi-threaded yet) from around early 2005. I know it wasn't top of the line when I bought it (I think the 248s were out by then).
It's the 2GHz core with 3GB of PC3200 RAM running WinXP Pro 32bit. The motherboard is a Tyan Tiger K8W S2875 with a slightly odd memory path. Only one of the Opterons is connected to the memory, the 2nd Opteron routes its memory access through the first one. It's not ideal, but it was the smallest form factor dual-CPU motherboard I could find at the time. (The newer K8WE S2877 has separate memory banks for each CPU.)
At some point I'll upgrade to the S2877 board with a pair of dual-core Opterons. Probably the 280s (2.4GHz) once they get below the $250-$300 mark.
I use GPG as well, but I keep each password in a separate text file. That way, even if someone shoulder-surfs me, they can only see a single password.
Most passwords that I use are randomly generated using a custom script that I wrote (a dictionary of 300k words combined with numbers, caps and symbols).
Look into using a password safe or keeping seldom-used password / account information in GPG-encrypted text files. That way you only have to remember a core password / passphrase to get at seldom-used secrets.
For the GPG method, create a new text file for each resource. Open it up in notepad, type in the access information. Then copy the contents to the clipboard and encrypt it before pasting it back into the text file. Now you have a secure secret that you can put anywhere (shared folder, mailed to your home or webmail account, or printed out and left on a desk). Plus it's easy to backup.
If / when you need access to that secret again, open up the text file and decrypt the contents.
I divide my passwords up by classification:
1) The ones I deal with on a daily basis. These number in the range of about 1 dozen, but are still easily rememberable. Length varies from 12-30 characters, includes digits, mixed-case and is comprised of multiple words. Memorable, typeable, and fairly secure. Some of the longer ones are 40-80 characters in length, but they are ones that I only use when booting up the laptop every few weeks. I use them all frequently enough that they're memorable (although I still back them up in a GPG-protected file).
2) The ones that I let the web browser remember. Such as forum passwords. Since I use a laptop that I keep secure, I'm not terribly worried about letting the web browser remember these. Those passwords are generated by a random algorithm and are usually 20-40 characters in length with random caps and symbols inserted into the middle / ends / beginning. I keep track of these by placing them in a text file prior to encrypting to contents of the text file with my GPG key. If I ever need to look them up, I open the text file, copy the contents to the clipboard and decrypt it.
3) Other seldom used passwords. These are almost all randomly generated (30+ characters with random sybols, digits and caps). Again, I simply store them in plain text files where the contents of the file is a GPG encryption block. To get at the password, I copy the contents into the clipboard, decrypt and there I have it.
The plain text file with GPG encrypted contents works well for many reasons. It's backup-friendly (I could even put the contents into source code control), I can e-mail the blocks to myself on other machines without worries or I can make backups of all of my passwords by mailing them to a webmail account. I can setup the contents of the file to be readable by my co-workers for cases where multiple of us need access to the password.
Sounds like your company is about the size of ours (less then 50 employees). We have a variety of backup schemes, depending on the user.
For our remote workers using laptops, version-control software for corporate data and staying in sync with the other workers in their department. Combined with SecondCopy + TrueCrypt partitions on the USB/FireWire drives. The local USB/FW drive handles things like backing up their personal files or e-mail. We also recommend that they make use of a tool like Acronis TrueImage / Knoppix+NTFSClone / Ghost to make snapshots of their system. TrueCrypt works well as a backup target in this scenario because SecondCopy is a user-space tool rather then a background service.
For the corporate server backups, we run a two-stage system. We have an onsite server that is large enough to hold 2 weeks of backups on disk. This server is always available so there's no worries about drives not being ready. The primary backup runs at night during off-peak times. Then, during the day, we use a workstation to copy data from the backup machine to removable hard drives.
I'm experimenting with using TrueCrypt on those removable hard drives. The secondary backup workstation is always up and running (with a user logged in) to perform other tasks, so it should not be difficult for us to keep the TrueCrypt volume mounted. Or I could use the command-line features of TrueCrypt to automatically mount/dismount the volume. But I'll probably simply opt for leaving the drive mounted until it's time to remove it. (The removable drives are PATAs installed in StarTech DRW115 series bays/trays.)
We take our backup drives offsite weekly (with a current rotation of 6 drives, slowly expanding to 12 drives). Tape was too finicky for us. I had originally considered encrypting the target data using a GPG public-key as it was copied to the drive, but that is slow and tedious for recovery. EFS was a non-starter due to the portability issues, but TrueCrypt looks like it has the right level of security combined with ease of use.
Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.
BTW, TrueCrypt includes a little benchmark tool to allow you to calculate throughput rates for the various algorithms (as implemented inside of TrueCrypt). Useful for seeing just what the best-case rates are for a particular CPU. On the Opteron 246, they stack up as:
Blowfish (47) > Twofish (41) > CAST5 (35) > Serpent (34) > AES (33) > Triple-DES (12)
Where (NN) is the mean speed in megabytes/sec for encryption/decryption rates. Your data rates will vary on other CPUs and on other motherboards.
The submitter's question linked to truecrypt as one of two programs he's tried and found not fast enough. I hear it's real nice, but he's already found it too slow for his needs.
I'm also amused by the submitter's "too slow" comment for TrueCrypt. I use it on my 4-year old laptop (a 1.7Ghz Pentium 4 mobile) and find that it's the hard drive that is the bottleneck rather then the CPU. I'm using the stock TrueCrypt settings for encryption algorithm (256bit AES, LRW mode) and hash (RIPEMD-160). I have two volumes on the laptop, one is a ~700MB TrueCrypt file volume used for extra sensitive data and the second is a full-disk encrypted FireWire drive attached to the unit (160GB).
Copying from the laptop's hard drive to the encrypted external FireWire drive gives me transfer rates of around 10-12MB/sec and uses up around 30% of my CPU. Which is not too shabby for a 4 year old laptop. I would hardly call it "too slow".
I just did the benchmarks for a 100MB buffer, the left number is speeds on my 1.7Ghz Pentium 4 mobile laptop CPU, on the right is performance of a 2Ghz Opteron 246 chip (TrueCrypt 4.2 is not multi-threaded so it only used one of the two chips installed in that system):
Blowfish 35.1MB/s 46.8MB/s
Twofish 21.3MB/s 40.6MB/s
AES 28.5MB/s 32.6MB/s
Serpent 11.7MB/s 34.3MB/s
CAST5 10.5MB/s 34.7MB/s
Triple-DES 6.2MB/s 12.0MB/s
Those are not scientificially rigorous tests, but the built-in benchmark tool shows that the laptop's P4 is capable of very high encrypt/decrypt rates. It also looks like Serpent/CAST5 algorithms possibly don't fit inside the CPU cache very well (the Opteron chip has a larger L2 cache) or Serpent/CAST5 use operations that are more efficient on the Opteron chip. I don't know enough about the individual characteristics to make more educated guessed then that.
It's a pity that TrueCrypt isn't multi-threaded, or the dual-CPU Opteron system would've scored even higher on the TrueCrypt benchmark. I've run the benchmarks for a few different sizes (10MB / 50MB / 100MB / 500MB) and the numbers all tend to add up the same way (within a few percentage points) across the board.
The big problem with NTFS encryption (a.k.a. Windows EFS) is that:
- The keys are tied to the machine (you can't take those USB drives and mount them on another machine, at least not when I tested it)
- The keys are a PITA to backup, the management interface is clunky
- It's not the strongest system in the world (I believe there are numerous issues with how it was implemented)
That being said, it's generally better then nothing for when you want to protect semi-confidential data. Most attackers won't take the time to break it.
But for external USB backup drives, I strongly recommend you consider switching to something like TrueCrypt. Just create a partition, don't format it or assign it a drive label, then let TrueCrypt create a 'device' volume on the partition. You'll be assured of being able to take it from machine to machine with no worries as long as you know the passphrase and/or have the keyfiles for the volume. Works very well for laptop-centric backups using tools like SecondCopy where your target volume is the encrypted USB/FireWire drive.
If the crypto is done right, shouldn't destroying the keys and maybe some random parts of the file be enough to completely remove any hope of recovering the data?
If I understand TrueCrypt's technology and assuming that you didn't let an attacker copy your TrueCrypt volume header... overwriting the first 512 bytes of a TrueCrypt volume destroys the key for that volume. Unless you have a backup of the volume header, your data is lost and unrecoverable unless you get lucky and can break the encryption key.
So it's (theoretically) a lot faster to destroy the contents (or at least make them inaccessible to anyone) with a encrypted volume file like TrueCrypt uses. I can't say for sure whether PGPDisk or DriveCrypt use the same sort of storage system (with the encryption keys stored at the start of the volume file).
All this new harddrive tech is cool and all, but what I want more than anything else, including more and more massive storage, is better reliability.
In the past year or so, I've had, literally, 50% of all drives I have purchased fail. Mostly Western Digitals, FWIW.
For that matter, I've had several expensive raid controllers fail too. This shit is really starting to piss me off.
Odd, because I haven't seen a drive fail in quite a while personally (and I probably have 20+ spindles sitting next to me in my office). I have a mix of Seagate, Maxtor, Hitachi and Western Digital.
As always, the #1 killer of drives is heat followed by poor power. Mechanical damage is also possible, but not likley in stationary systems.
So, what operating temps were you running at? Were you using a line-conditioning UPS to correct over/under voltage situations? Was your power supply a no-name cheap one or a quality one with good tolerances?
Because a lot of sites use smaller text for footer information. Which isn't what I consider "main" content. So if I set my minimum font size to be equal to my desired font size, it causes issues where text that should be small (8 point instead of 10-12 point) looks odd.
The core problem is that well-behaved and well-designed sites shouldn't force a font size on the user for primary content.
Agreed, I started by learning BASIC (numerous incarnations up through GW-BASIC) about 20 years ago. Then came FORTRAN, followed by Pascal, followed by C. A few years of C++, then some VBScript followed by some VB, Java, with a smattering of Perl. Oh and some REXX thrown in for good measure along with DBase III/IV and CA-Clipper.
Needless to say, new languages don't really scare me anymore. New languages shouldn't scare any experienced developer. Very rarely does a new language come up with entirely new concepts, so it's just a matter of learning the syntax and finding the various tips/tricks.
Right now, I'm trying to decide between PHP / Python / Ruby or just chucking it all and going back to Perl.
Well, for our small group of 5 developers, 4 of which are off-site 95% of the time... VSS+SOS has worked well. It probably helps that none of us are using the VSS client (instead, interfacing through SOS). Since a lot of the stuff we work with is binary files, the checkout-modify-checkin model works well.
I can't say that I've had an issue with VSS/SOS in the past 6 years. I'm well aware of its fragility and we have very very good backups. But it's treated us well. The main reason that we're looking to migrate away from VSS/SOS is licensing costs as well as cross-platform clients.
(Some companies / employees simply don't "get" the idea behind source control systems. Which is a training issue and not a technical issue. When I first introduces the VCS concept at my previous job, it took a month of evangelizing to get the developers to use it. Prior to that, they weren't using *any* VCS and VSS was vastly better then nothing.)
Have you documented your setup at all (or described the technical details) anywhere?
We're a Visual SourceSafe shop that uses SourceOffSite for our remote workers. I've been experimenting with SVN+Tortoise+SSH, but I'm finding it to be a bit slow on our test server. I know I gave up trying to setup Apache the last time that I attempted.
How are you connecting to SVN? Apache? SVNServe? SSH or SSL? Do you have offsite workers?
I run Firefox 1.5 on a 125ppi display (14" 1400x1050 LCD). My minimum font size is set to "14px". The new CSS style makes the text a bit screwy and slightly too small. My preferred font size is 18px.
The problem is that their CSS sheet specifies "14.75px" for the normal text. Which looks fine on 96ppi displays, but is horribly tiny on 125+ ppi displays. That works out to 14.75/125*72 = 8.5pt font size when my preferred size is 10pt text.
(Hint to web designers... stick with "small/normal/large/etc" tags or switch to using "pt" suffixes instead. Specifying font sizes in "px" gets you into trouble.)
I haven't decided what to do yet about Slashdot. But the readability of the site has taken a huge nosedive with the new CSS look.
Well, a few years ago it might've been necessary... it all depends on how fast your data is streaming in from your soundboard. Assuming 96kHz, 32bit, 8 channels, we get a data rate of 384KB/sec per channel or a bit over 3MB/sec for 8 channels. That's not a lot of bandwidth for modern systems.
Back when I was recording raw video (720x480, 60 interlaced frames, HuffYUV) it required a data rate of 8-9MB/sec (too lazy to go back and look for certain). Back in the 20/40GB drive days, hard drives had difficulty in writing that amount of data to the disk continuously. But with the newer 200+ GB drives, they can sustain transfer rates in the 20-40MB/sec range.
So if my 3MB/sec estimate is accurate for audio recording... that's easy for most modern hard drives to handle. Even if the drive isn't perfectly defrag'd, you shouldn't run into issues. Especially if you're recording to a dedicated spindle (i.e. a drive that is not handling other requests for data).
OTOH, if studio time is a factor, then the move/wipe/reload may be cost-effective to not have to worry about it at all.
You've apparently never seen how ugly DVD looks on a large screen.
Some of that depends on the decoder quality. Granted, I don't have a 90" screen but on my smaller 23" HDTV it's easy to see the difference on DVDs between a good/bad decoder. My cheap Sony DVD player looks horrid, even using Component output. The Samsung DVD player with upscaling looks a little better. But the best display is when I output Zoom Player Professional to my HDTV via VGA cables.
Yes, moving the data off, re-formatting, and moving the data back on is indeed a sure-fire defrag method. As the files are copied back onto the fresh volume, they automatically lay down as non-fragmented files. It's a bit stone-age now that Windows includes a built-in defrag tool (since Win2000 started shipping). (Back in the WinNT days, you had to pay extra for NTFS defrag tools.)
Modern hard drives are also less prone to bad sectors (the drive checks for these when writing and does re-mapping on the fly). For most SMART-capable drives, once you start seeing bad sectors in the output of the FORMAT command, it means that the drive has run out of rewrite sectors and is starting to fail. (I'm a bit hazy on how it all works under the covers.)
Thanks for the pointers to the newer M4/M5.
We've used Tecras since 2000 for a few reasons: 1400x1050 display, the AccuPoint / TrackPoint mouse pointer, and previous good experience with Toshibas. The Tecras seem to hold up to a decent amount of abuse (I travelled on a monthly basis in 2000-2002, usually week-long trips.).
I have a Toshiba repair depot about 25 miles away, which is convenient enough for me (it's a nice country-drive to go across the river to drop-off / pick-up). So service has never been a big issue. Typical failures are moving parts such as the CPU fan or the hard drive (which I replace myself). The warranty service has been good enough (a 5-year warranty would be welcome).
I'm not real fond of the M4 design, but the M5 looks as sturdy as my current 9100. (My objection to the M4, sight-unseen, is the swivel hinge for the screen.) We've also purchased a Thinkpad T43 in the past and that user is very pleased with it. We were considering the newer T60 as well, but we'll probably stick with Toshiba for as long as they include the high-res screens and the AccuPoint.