Thursday, August 26, 2004
US company shifting software development facilities to Pakistan - PakTribune: "SLAMABAD, August 06 (Online): Halliburton's Landmark Graphics Division, a US-based company, announced Thursday it had decided to migrate some of its main software development centres in Norway to Pakistan through its majority-owned company LMK Resources and it was further looking at the possibility of transferring some major projects started elsewhere to Pakistan."
Electoral Vote Predictor: "Welcome to Electoral Vote Predictor 2004, which tracks the electoral vote (EV) state by state. In 2000, Al Gore won the popular vote by over half a million votes but George Bush won the electoral vote by 5 votes and became president. Thus watching the electoral vote is more important than watching the national polls. This website is dedicated to tracking the electoral vote by examining the state-by-state polls. As new state polls are released, the maps, spreadsheets, tables, graphs, and movies will be updated. In the maps, the white states are essentially tossups and are subject to rapid fluctuations. The magic number needed to be elected is 270."
There is also another site doing something pretty similar.
Electoral-vote.com is run by someone who admits to being a Kerry supporter. ElectionProject.com by someone more conservative. Interestingly, they both seem to be reporting similar numbers.
There is also another site doing something pretty similar.
Electoral-vote.com is run by someone who admits to being a Kerry supporter. ElectionProject.com by someone more conservative. Interestingly, they both seem to be reporting similar numbers.
Wednesday, August 25, 2004
Up and Over the Windows Firewall
(copied from an email sent to me. This may be on the web somewhere, but I just copied it here for reference purposes)
I installed Windows XP Service Pack 2 on my test system a few
weeks ago and started playing with it. A lot of what I call
"playing" entails remote administration and management. I wanted
to see what SP2—especially the much-hyped new Windows Firewall—
would do for (or to) remote management. Naturally, it pretty
much broke everything.
The first thing I noticed was the constant warnings that my XP
system wasn't running an antivirus package. For legal purposes,
Microsoft made XP SP2 complain incessantly until you installed
antivirus software, which you had to purchase from another
software company. I'm OK with that. We should all be running
antivirus software and I don't mind being reminded.
But the minute I tried to Remote Desktop into my newly service-
packed machine, I was stymied. Nothing connected. Windows
Firewall, it turns out, works spectacularly. You just can't touch
a remote XP box once that firewall is running. This is somewhat
irritating when I've got several clients making heavy use of
remote management scripts that are now, essentially, useless. I
know I can control the Windows Firewall through some Group Policy
settings, but my test XP box isn't a domain member, so I wanted to
look at alternatives.
I found the start of a solution on the blog of a Microsoft
Scripting Guy. Seems Windows Firewall is accessible to VBScript.
He provides the following four lines of code to set the firewall
to allow RPC connections, which is what Windows Management
Instrumentation WMI and many other remote management scripts need
to operate:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = TRUE
Problem is, you have to first get the script onto the machine,
which is near impossible with Windows Firewall running. In a
domain, you might assign the script as a logon script or startup
script and it'd take care of business. You can do a better job
with Group Policy, allowing incoming RPC connections only from the
local subnet, for example, if that's where you'll be running
management scripts.
Obviously, you need to use a script like this with some caution.
Make sure you're not opening a hole bigger than you need—the
firewall exists to help protect client machines and if you
indiscriminately shut it off or punch it full of holes you're
defeating that protection.--Don Jones
(copied from an email sent to me. This may be on the web somewhere, but I just copied it here for reference purposes)
I installed Windows XP Service Pack 2 on my test system a few
weeks ago and started playing with it. A lot of what I call
"playing" entails remote administration and management. I wanted
to see what SP2—especially the much-hyped new Windows Firewall—
would do for (or to) remote management. Naturally, it pretty
much broke everything.
The first thing I noticed was the constant warnings that my XP
system wasn't running an antivirus package. For legal purposes,
Microsoft made XP SP2 complain incessantly until you installed
antivirus software, which you had to purchase from another
software company. I'm OK with that. We should all be running
antivirus software and I don't mind being reminded.
But the minute I tried to Remote Desktop into my newly service-
packed machine, I was stymied. Nothing connected. Windows
Firewall, it turns out, works spectacularly. You just can't touch
a remote XP box once that firewall is running. This is somewhat
irritating when I've got several clients making heavy use of
remote management scripts that are now, essentially, useless. I
know I can control the Windows Firewall through some Group Policy
settings, but my test XP box isn't a domain member, so I wanted to
look at alternatives.
I found the start of a solution on the blog of a Microsoft
Scripting Guy. Seems Windows Firewall is accessible to VBScript.
He provides the following four lines of code to set the firewall
to allow RPC connections, which is what Windows Management
Instrumentation WMI and many other remote management scripts need
to operate:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = TRUE
Problem is, you have to first get the script onto the machine,
which is near impossible with Windows Firewall running. In a
domain, you might assign the script as a logon script or startup
script and it'd take care of business. You can do a better job
with Group Policy, allowing incoming RPC connections only from the
local subnet, for example, if that's where you'll be running
management scripts.
Obviously, you need to use a script like this with some caution.
Make sure you're not opening a hole bigger than you need—the
firewall exists to help protect client machines and if you
indiscriminately shut it off or punch it full of holes you're
defeating that protection.--Don Jones
Monday, August 23, 2004
Debugging application startup when you don't directly launch the app: Matt Pietrek's blog discusses a cool way to launch a debugger on windows. Allows for the debugger to start the app and get involved VERY early.
