Here's the deal: Science is skepticism. No theory is 100% correct, and long-held axioms tend to be disproved by new evidence (just ask Aristotle or Newton). By saying, "I am a scientist", you acknowledge that whatever you believe to be true today can easily be demonstrated as being false by some new datum tomorrow. And I say "tough toenails" to anyone who wants the title of "scientist" but isn't willing to be intellectually rigorous in this regard. That's right - every belief, every axiom, every hypothesis, every theory, every rule, every "law" must be, in a scientist's mind, tagged with a confidence factor that never, ever hits 100%.

Now, this is just what I believe. I could very well be wrong.

As an I.T. worker and as an employee, you have a moral duty (if not a fiduciary one) to your employer and to your fellow employees to protect them from legal or other threats to the organization. Part of that duty entails things like doing your job competently, avoiding security risks (like propping doors open or not locking your workstation), and so forth. Regardless of the direction from your management, you would be acting negligently if you did not confirm software licensing status to your satisfaction before deploying said software. You can and should say something like, "I can't install this version of Office because it is clearly unlicensed - you can find the CD key on Google." Or: "I need the original media to install this program."

It gets more complicated when your employer uses software subscriptions or some internal software deployment mechanism instead of retail purchases installed by hand. You should still verify compliance as best you can, given that you may not have access to the official digital distribution site, license key list, or subscription terms.

Business people think in terms of risk, so if they require you to justify your actions (because they see you as being obstructionist instead of dutiful), you need to be ready with compliance costs versus potential infringement judgment/settlement costs along. I'm sure BSA has suitably terrifying numbers on their web site. Some managers refuse to see reason because they are incompetent (they don't understand the software license terms) or unethical (they are willfully violating the licenses), which should indicate to you that you need to find new employment. Companies with bad management aren't a good place to work and may not last very long, and in today's economy, you need a lot of time to look for a new job. I think that it's better to start your search while you still have a paycheck and medical insurance.

Thank you both for your responses!

"Ran" can mean "totally pwned the computer", but "ran" can also mean "started execution but couldn't do much other than start spamming/portscanning" (which is, admittedly, bad enough). UAC is designed to prevent pwning computers, not stopping execution, so I'd like to know which happened.

Would someone please explain in terms comprehensible by a non-specialist (me) why GR and QM are incompatible? I keep reading this assertion, but I don't really know enough about the details of either theory to understand why they are incompatible.

I'll second the recommendation of Windows 7. The tablet PC features in Vista and 7 work much better than those in XP (IMHO), and Win7's memory footprint and overall performance appears to be much smaller/faster than Vista's. My only complaint is with Intel and Microsoft not writing an updated (WDDM) driver for their older displays. While I was able to get the older (XDDM) driver working under Vista, I cannot seem to find the right combination of sacrificial chickens and unholy incantations required to make the very same driver work under 7 (even though others report success) - a common complaint among those of us stuck with laptops featuring the Intel Graphics Extreme/Extreme 2 (mine's an Electrovaya SC2200).

I wonder what's the MTU of pigeons these days. With modern micro-SD cards, it's got to be north of 8 GB. I'm pretty sure that's bigger than IPv4 can accommodate.

We have similar needs, only we're exchanging files across dodgy Internet connections (e.g., satellite links to sites in the developing world). Our requirements including operation over low-bandwidth connections and the ability to suspend and resume transfers. We settled on Windows Live Sync, since it works on Mac OS X in addition to Windows, and because it required no additional software development effort on our part. Had Live Sync not been available, we would have developed our own wrapper around BITS. Because BITS is an extension to HTTP, it degrades gracefully into something interoperable with non-Windows clients. (BITS would also work over a private network, but that wasn't a feature we required.)

I store users' roaming profiles and home directories on a server running Windows SBS 2003. The server's storage is a SATA RAID-5 (3ware rocks!). SBS backs itself up to disk weekly, which I occasionally transfer to an external hard drive for DR purposes. The profile and home directories are separate SMB shares because the share containing the roaming profiles is configured to disallow client-side caching (which causes problems with the user profile loader on older versions of Windows and maybe even Vista). The shares are accessed via MSDfs because some day I'd like to replicate them to a second server and want any accesses or fail-over to be somewhat automatic (again, for DR purposes). I use Group Policy to move each user's "AppData", "Contacts", "Desktop", "Documents", "Downloads", "Favorites", "Links", "Saved Games", and "Searches" folders to their home directory. In my scheme, "Music", "Pictures", and "Videos" are sub-folders of "Documents", for backwards compatibility with Windows XP. I've also configured Volume Shadow Copy, which allows users to retrieve older versions of their files without needing to bother me about restoring them from archival backups, and deployed Certificate Services on SBS. Each user's enrolled in the domain PKI, so they can encrypt their caches as well as any of their files.

From the users' perspective, everything is automatic: They log in, work with their files, and log out. If they are out of the office, they'll get a warning about working with a cached copy of their profile, but that's about it. When they return, they'll get prompted to sync any conflicting changes made while offline. Windows has featured CSC (also known as "Offline Files") for some time, but it's only gotten really stable in Windows Vista. A few programs don't really play well with CSC but nothing that's a deal-breaker (like Firefox or Skype storing database stuff in the roaming version of the AppData folder when it really should be in local version instead, but I kind of brought that on myself when I redirected it to the network share to start with).

Does NoScript prevent .NET applets from running unless I explicitly trust the site? If so, then no big deal as I would have gladly downloaded this functionality separately had I know it existed (which is what I have to do with Java on all my Windows boxes).

You also might notice that both Silverlight 2 and Office 2007 add plugins to Firefox, again behavior that is congruent with at least Adobe Acrobat and Flash. And - happy day - their execution is controlled by NoScript, so I don't mind that at all.

If anything, I'm glad to see Microsoft supporting alternative browses. I'm almost certain that these efforts are driven by anti-trust judgements against them in a number of different jurisdictions, but that's fine with me, too.

Wait, what? Tequila shots aren't what life wants me to do with the lemons it just handed me? I can't believe I had it wrong for so long and no one said anything!

I'm not talking about hacking a single computer. An attacker doesn't necessarily have access to the victim's computers. What if someone stole the backup tapes for the victim's authentication servers (Active Directory or OpenLDAP or whatever)? Eventually, the theft will be discovered, but if the passwords are weak enough to be easily cracked, the attacker may be able to cause plenty of damage in the time between the theft and its discovery. Getting back to my original point, you are trying to slow attackers down or force them to do things that make them easier to detect. Some jerk spewing exploit code all over a network is fairly easy to spot. What could be legitimate resource accesses from properly authenticated accounts are much more difficult to detect and repudiate.

Yes, passwords are individually hashed. I should have said something like "when a significant number of the passwords are decoded".

I'm not sure I understand how that's relevant. Usually, exploits allow attackers to gain privileged access to their target. In any case, that's merely one source of password hashes. There are numerous others available to attackers (e.g., packet captures of vulnerable challenge/response protocols).

You misunderstand the risk. Password complexity policies offer protection in case the password database itself is compromised, when account lockout policies are of no use. The idea is to give everyone enough time to change their password before the attacker is able to decode the database (or authentication caches or packet captures or whatever).