You are correct, technically, but the real value of these kind of two-factor authentication techniques is that they are immune to replay attacks. Someone listening in to the Apple login process can't re-use the transmitted SMS code, because Apple expects to see a different code each time you log in.
See if you pick up some of the interface technologies for the equipment you're already familiar with: UPS, ATS, Air Conditioner, Generator, PDU, remote sensors. Most modern infrastructure like this has hooks for SNMP or Modbus, and few vendors (even the folks who manufacture these items) know what to do with these, or even what *can* be done with them. If you can also pick up an open source monitoring system like Nagios, and some basic networking, and a bit of Perl, you can put together inexpensive infrastructure monitoring. If you can talk your current employer into letting you play around with this stuff, then you both win, and you are doing fun stuff that is less physically demanding.
Ham Radio is a great hobby for someone like your dad. There are technical, social, competitive, and public service aspects to it, and there are so many areas of interest within the hobby that any technical person can find one or more things to pursue. Check out the information and publications at the ARRL (arrl.org) web site.
Check out Norsam's HD Rosetta product (http://www.norsam.com/hdrosetta.htm). An inert nickel plate, etched with a focused ion beam. It's supposed to last 1,000 years, and it's readable with a microscope.
Some big-iron-type products out there require some kind of proprietary infrastructure to be built around them in order to take advantage of all of their special features. Examples would be requirements of particular web browsers or browser plug-ins, particular network services, etc.
In the case of software, do they require certain files to be in odd, non-configurable locations in a file system? Does the software make good use of the services of the OS (syslog, inetd,/etc/init.d, DNS, LDAP)?
I always look for "lowest common denominator" access, i.e. will I be able to manage this hardware or software without too much pain using a CLI over a low-bandwidth connection.
Also, how fussy will the vendor be with regard to self-maintenance? Do they have intelligent people on their support lines who will listen to my opinions, or are they script-reading drones who just want to point a finger at another vendor and get you off the phone? Will they even let you change the hardware or software configuration without a tech being there?
We have 23 DS-10 Alpha boxes that were left over after we retired our old render farm. They are four years old, but still have the horsepower to make dandy network servers (though we run OpenBSD on them). And the SRM console is very powerful and makes them true machine room servers. I can even reset them and cycle power via the serial port, using the RMC (Remote Management Console) feature. They are great workhorse machines. Thanks DEC!
Advice gleaned from years of bitter experience
on
Renderfarm Setup Tips?
·
· Score: 3, Informative
Having built two generations of renderfarms, and
now working on a third, I'd suggest building it
as cheap as possible. You will want to
upgrade every 2 years or so, so make sure that
you won't feel bad disposing of the old farm when
it's time for the new.
Regarding networking: you have to look carefully at
the way the farm will be used. If you are doing
any kind of compositing (which requires high I/O
rates), you'll benefit from gigabit ethernet.
You'll also benefit from gigabit if you have exceptionally short render times (less than 30 minutes per frame), since in this
case I/O is a significant fraction of each frame's render cycle. But the longer your per-frame render time, the less necessary gigabit is. We've always used 100base and it still serves us well.
Fiber is expensive and provides nothing you'll need that copper can't provide.
The individual machines should have identical configurations and be interchangable. Your goal is to not care when an individual machine dies. In light of this, there should be no local storage of data. You can save money on support if you buy spares instead of service contracts. Warranties also work, but the big manufacturers give their worst service to warranty-only customers.
Don't wire anything but ethernet to the machines. KVM wiring is expensive and unnecessary. Each machine should run unattended until it dies; when it does, you can wheel over a monitor and keyboard to diagnose it.
Opterons are fast, compatible, cool, lower-power and cheap. Xserves are nice, but we've found that Darwin doesn't integrate well into a pure Unix environment. You'd also be locking yourself into a single manufacturer.
Linux is cheap and effective, and easier to configure correctly as a server OS than as a desktop OS. There is so much commercial software available for it now that there is little reason to consider Windows or a commercial Unix. We haven't found Linux support from the big manufacturers to be all that great; if you use Linux, assume that you will have to solve most problems on your own.
Slashdot Mirror
You are correct, technically, but the real value of these kind of two-factor authentication techniques is that they are immune to replay attacks. Someone listening in to the Apple login process can't re-use the transmitted SMS code, because Apple expects to see a different code each time you log in.
See if you pick up some of the interface technologies for the equipment you're already familiar with: UPS, ATS, Air Conditioner, Generator, PDU, remote sensors. Most modern infrastructure like this has hooks for SNMP or Modbus, and few vendors (even the folks who manufacture these items) know what to do with these, or even what *can* be done with them. If you can also pick up an open source monitoring system like Nagios, and some basic networking, and a bit of Perl, you can put together inexpensive infrastructure monitoring. If you can talk your current employer into letting you play around with this stuff, then you both win, and you are doing fun stuff that is less physically demanding.
Ham Radio is a great hobby for someone like your dad. There are technical, social, competitive, and public service aspects to it, and there are so many areas of interest within the hobby that any technical person can find one or more things to pursue. Check out the information and publications at the ARRL (arrl.org) web site.
Check out Norsam's HD Rosetta product (http://www.norsam.com/hdrosetta.htm). An inert nickel plate, etched with a focused ion beam. It's supposed to last 1,000 years, and it's readable with a microscope.
Even when it's bad, it's still pretty good.
Some big-iron-type products out there require some kind of proprietary infrastructure to be built around them in order to take advantage of all of their special features. Examples would be requirements of particular web browsers or browser plug-ins, particular network services, etc.
/etc/init.d, DNS, LDAP)?
In the case of software, do they require certain files to be in odd, non-configurable locations in a file system? Does the software make good use of the services of the OS (syslog, inetd,
I always look for "lowest common denominator" access, i.e. will I be able to manage this hardware or software without too much pain using a CLI over a low-bandwidth connection.
Also, how fussy will the vendor be with regard to self-maintenance? Do they have intelligent people on their support lines who will listen to my opinions, or are they script-reading drones who just want to point a finger at another vendor and get you off the phone? Will they even let you change the hardware or software configuration without a tech being there?
We have 23 DS-10 Alpha boxes that were left over after we retired our old render farm. They are four years old, but still have the horsepower to make dandy network servers (though we run OpenBSD on them). And the SRM console is very powerful and makes them true machine room servers. I can even reset them and cycle power via the serial port, using the RMC (Remote Management Console) feature. They are great workhorse machines. Thanks DEC!
Regarding networking: you have to look carefully at the way the farm will be used. If you are doing any kind of compositing (which requires high I/O rates), you'll benefit from gigabit ethernet. You'll also benefit from gigabit if you have exceptionally short render times (less than 30 minutes per frame), since in this case I/O is a significant fraction of each frame's render cycle. But the longer your per-frame render time, the less necessary gigabit is. We've always used 100base and it still serves us well. Fiber is expensive and provides nothing you'll need that copper can't provide.
The individual machines should have identical configurations and be interchangable. Your goal is to not care when an individual machine dies. In light of this, there should be no local storage of data. You can save money on support if you buy spares instead of service contracts. Warranties also work, but the big manufacturers give their worst service to warranty-only customers.
Don't wire anything but ethernet to the machines. KVM wiring is expensive and unnecessary. Each machine should run unattended until it dies; when it does, you can wheel over a monitor and keyboard to diagnose it.
Opterons are fast, compatible, cool, lower-power and cheap. Xserves are nice, but we've found that Darwin doesn't integrate well into a pure Unix environment. You'd also be locking yourself into a single manufacturer.
Linux is cheap and effective, and easier to configure correctly as a server OS than as a desktop OS. There is so much commercial software available for it now that there is little reason to consider Windows or a commercial Unix. We haven't found Linux support from the big manufacturers to be all that great; if you use Linux, assume that you will have to solve most problems on your own.