Forgot your password?

Comment: Re:more than I can technically achieve over wirele (Score 1) 279

Don't forget a snake to chase the cables through the walls. Getting the cable from the attic to the right level at the wall is usually the hardest part. Depending on the home construction, it can be almost impossible.

I ran the surround sound speakers for a friend. The TV, receiver, etc, were in a corner of two outside walls. The standard local construction was concrete blocks, a 1x2 or 1x3 strip vertically, some very thin fiberglass and vapor barrier, and finally the drywall for the interior. Outside walls also have a double layer of 2x4 for the header.

Since you're working where the roof meets the wall, you usually barely have room to get a drill in, and definitely can't get close enough to see down the hole.

Inside walls are a lot easier, if you can use them. They don't usually have a header, nor insulation.

It helps to have a friend (but not to be the friend) who has done it before. It takes some pretty serious bribes to get me to even think about doing it. :)

I always suggest wired over wireless. It will always be a better connection.

Comment: Re:So offer a cost effective replacement (Score 1) 185

by JWSmythe (#48007299) Attached to: Security Collapse In the HTTPS Market

I really liked PayPal's solution for limiting risk when paying sites that didn't support PayPal. Their Virtual Debit Card product was great. I could provide whatever information I wanted, restrict the virtual card to exactly the amount of the transaction, and optionally allow it for recurring transactions. They were awesome, especially when purchasing from small companies with very little information about if they were legitimate or not.

PayPal if nice and all, but plenty of people fall for the common traps, like variations on the domain name which are phisher traps.

People here were generally better at avoiding scams, but that doesn't help the > 90% of the population who never check.

Comment: Re:Read Slashdot (Score 2) 479

by JWSmythe (#47981319) Attached to: Ask Slashdot: Finding a Job After Completing Computer Science Ph.D?

The rejections you got may not have been because you didn't know a specific answer to a very technical question.

Something I've come across in the past is something similar. It's not knowing the specific answer. Sometimes it's knowing what specific answer *they* want.

For example, "How can you change the IP on a current RHEL or CentOS box".

There are a bunch of right answers.

  • edit the appropriate /etc/sysconfig/network-scripts/ifcfg-eth* file.
  • system-config-network
  • /usr/sbin/system-config-network
  • use ifconfig directly (not durable through a reboot, but ...)
  • change the static entry on the dhcp server for that network interface
  • modify it in cfengine, and wait for it to update.

... and those could all be wrong. That particular shop may say "We don't trust ifcfg-eth*", "system-config-network mangles the file format", or even "we don't use those files, we use /etc/rc.d/rc.inet1, that the old admin 10 years ago wrote". It could even start with "fill out the production change review forms, and submit them to the change review committee".

Some places insist that you use the full path to scripts, in case someone else put one farther up in your path (like /bin/). Some don't allow sbin to be in the user's path at all. And of course, if you failed to say "use sudo", you're one of those renegade admins who thinks they can run commands as root. Not knowing *their* method, even though you've never worked for them, is enough to fail an interview.

When I've been interviewing people, I don't work from a hard set of answers. If the interviewee comes close enough, they got it right. If they gave the "system-config-network" answer, I'd just ask "Do you know what files that modifies related to IPs?"

I've interviewed with Google a few times. One of the questions they asked was "How does telnet work?" I answered, and the interviewer asked me the question again. I gave the brief description, the detailed description, all the way down to the opening of sockets and how TCP works. Finally I just had to tell him, "I'm not sure what you're looking for in the answer. Can you please clarify the question?" He didn't. I don't know if that was a pass, fail, or just a stress question.

Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms.