I deal with wireless internet, you know, putting a high gain 2.4ghz antenna on a roof and providing internet to customers via 802.11b stuff.
This is what I tell most of our customers when they ask about lightning: "If your antenna is directly hit you're pretty much screwed". (Acutally this might be a good place for an appropriate goatse.cx link to illustrate how badly screwed).
I then go on to say that 99.9% of the damage is actually not caused by a direct hit. In fact, the purpose of most "lightning arrestors" is really to drain/discharge the static an antenna picks up.
This also applies to Power/Phone/Satellite TV, etc. etc. etc.. If lightning hits the pole outside your house, you probably will loose equipment. My personal experience is that even if the stuff doesn't immediately fail, you will have ongoing problems with anything exposed to that level of problem. Yes I've seen it.
That said, you can protect yourself in most less extreme cases. Unplugging EVERYTHING is always the best option but in reality isn't really an option for most people. The path I take is to go buy the best surge suppressor and/or ups that you can find. I personally prefer APC's. Most, if not All APC units include an equipment replacement guarantee so if you do take a direct hit you're covered. Remember to supress EVERYTHING. The power line, the phone cord, the satellite antenna cable plugged into the satellite receiver attached to the same power strip, etc. etc. etc. Lan surge supressors are highly recommended, especially if you go anywhere near outside with the cables, or to a "non protected" hub or similar.
Generally for the protection warranty to be effective you must make sure everything is protected or the warranty is void.
Hmmm.. I'm sure there's something else I wanted to add, but I'm not sure what, so I guess I'll quit rambling:)
And remember, off-site backup is always a great idea...
I'm not sure about other processors, but I know I get charged several different merchant rates:
The lowest rate for US Cards which the AVS (Address verification system) information matches what is on the cardholder's bank system.
A slightly higher rate for US cards which the AVS doesn't match.
A even higher rate (actually several different rates) for various international transactions.
Note that the difference (at least on my bill) is on a per-transaction basis, but that doesn't mean that other processors do something different.
The difference in cost is only a percent or two, but it can really add up.
I also suspect part of the problem is that companies are very hesitant to ship to an address that doesn't pass the AVS check, and I know for a fact that most international banks don't provide AVS information.
What a pairgain (and there are other equivalents) does is allow the phone company to put two or more lines on a single pair of copper. A lot of these (the non-digitial ones) actually use the high-frequency part of the wire (where DSL lives) for the second line. Thus, it would be impossible to provide DSL across these.
Add to the fact that there really isn't a copper pair between point a and b for both customers. Even if you could put dsl and pairgain on a pair, only one of the customers would likely be able to use it, unless you do something funky like line sharing, etc.
I was on a contract quite a while back where there were quite a few days where I had to find something to keep busy.
I learned perl. I had been hearing lots and lots of good things about perl and just hadn't had the time to learn it. I went out and got the O'Reilly book Learning Perl which I went through in about 3 days. Has been worth it's weight in gold ever since then. In fact, It saved my butt several times over this past weekend when I was doing a mail server conversion. I can't tell you how many scripts I hacked together to do this conversion or that one.
Your cup of tea might not be perl, but there's lots of other things to learn. There are also online courses you can take. Why not let your employer pay you for the time you spend getting a better education?
Of course, in my example, it was doubly sweet - it was a certain 3 letter government agency which was paying me $50/hour to sit there:).
I suspect that if palm is having problems that it's going to be very short lived. It seems (at least around here) that the handheld platform has finally hit "critical mass" which basically means everyone has to have one because everyone else is getting one.
As far as Palm vs WinCE goes, I'll take the PalmOS any day....
I'd buy some palm stock as soon as it dropped to the floor because of this news:).
I just got done building a pair of 1U rackmount servers: One was a 933 mhz Pentium III with 512MB of RAM and two 40GB hard drives for just over $1000, and one which was a celeron 733 with 512MB and one 30GB hard drive for around $600.
These are built from standard components: Specifically an intel CA810EAL motherboard ($141.44), Low Profile RAM (Kingmax PC150) ($101/512MB stick), Standard Floppy drive ($10), Thermaltake Low Profile Fan ($8), Standard IDE hard drive ($100ish depending on size), an a FCPGA CPU (Celeron 700's are $77). The case I buy from one of my suppliers for $179, but you can get them for about $225ish on the street.
The only gotchas are that you need to make sure that you use low profile memory and a low profile fan designed for a 1U case, but besides that it all just works.
You can also do dual-processor units, if you really need the CPU, but from your post, it doesn't sound like you're doing anything CPU intensive. The Motherboard mentioned above is a favorite of the "rackmounters" as it has built on Video AND an Intel Pro100 Ethernet card, so you don't even need to waste the 1 PCI slot you are able to get in a 1U case. (Note: There are some 1U cases which will let you use two pci cards, but they are few and far between)
I think what you will find however, is that the sun hardware doesn't really seem all that fast compared to the intel stuff. Besides that, you probably HAVE the spare components lying around if something fails.
This is real perl. Not VBScript. I have it running on my FreeBSD box. I'm using standard Perl Modules, for which there is one for about anything under the sun.
As for code size, I can't really argue one way or another. Speaking as a perl programmer, I'm not sure how you can get much smaller code-wise than a lot of perl scripts. From what I could see PHP was just perl with a slightly different (weird) syntax.
I fully agree with you, however, "real" VBScript-based ASP sucks. And is difficult to write, and so on and so forth.
I'm just used to using perl to do everything under the sun, and if I can do my web pages in perl in a "php-like" fashion it's a good thing.
I code in Apache::ASP which is basically a port of ASP to Perl. You write the code much like ASP- Basically you use a tool like DreamWeaver to generate the html and you then intermingle Perl in it. DreamWeaver recognizes each chunk as ASP code and handles it accordingly.
I find it very quick to program in. But again I've literally written megabytes of Perl scripts over the last 2-3 years, and I don't particulary want to learn PHP. If I didn't know perl, I might be inclined to look at PHP.
I use PLWeb Turbo (http://www.pls.com/) which is free. There is also a version for burning CD's.
The main problem I see is that it is a) no longer currently developed and b) platform-limited. However, it is a great product.
I'd switch if I could find another search engine which would do simple things like phrase/near searching, fielded searches, etc., etc., etc.,. The main problem is that most of the search engines are good for doing web-like searches where you don't need a lot of control over the search. Perhaps some of the other readers will be able to help.
I've thought several times about just writing a new search engine. Then I think about what is really involved.....:)
Can you say popping ears?
Seriously, With that much height difference, I wonder if there will be health problems. I know that going from sea level to about 5000 feet is a noticible oxygen difference.
Try going up 3000+ feet in 2 mins...
I would say that this would about have to be true.
Considering there were only 50 HTTP servers at the beginning of 1993 (7 years ago). When the ISP I still am on the board of directors for and do a lot of the techincal work for started in the 4th quarter of 1994 (see the registration for mt.net), we didn't even install web server software as we didn't see the need.
Besides, any server which had been up this long would have been rooted 3-4 times, subject to untold Denial of Service attacks, and would be generally unusable.
I can testify to the fact that hard drives don't like to be spun down after being on for a LONG LONG TIME. I was going to post with a subject of "Don't turn it off!" and have the message say "The drives will never spin up again", but I figured in this modern age of machines which get powered off once a week and drives which spin themselves up and down, noone would even know what I was talking about. However, most "old time" Novell people (myself included) generally know that if a server crashes, the WORST thing you can do is turn power off to the drives.
The phrase "I turned it off and back on to fix it" for a server which has been up for years usually brings cringes to most novell people.
The cause of the effect of drives not spinning back up is simple. While they're spinning, the head collects junk. When you turn the drive off, the head parks and the spindle stops spinning, and the junk on the head sticks to the platters, which in a lot of cases won't spin back up. There is also the issue of the bearings sticking and not restarting.
The trick that almost everyone learns at some point is that the data can be recovered from these drives occasionally (actually quite often) by getting another hard drive ready and then somehow getting the drive spinning. My favorite approach is to freeze the hard drive. Yep. The freezer overnight. If you don't believe me see
http://www.internetvalue.com/onsite/200ways.htm
I've also used quite a few of the other methods in here. IF you can get the drive spinning, it will usually work long enough to get at least the data you want off of it.
I usually don't respond to stuff like this, but...
Let me prefix this with I fully agree that the closer you can get to a True Sine Wave UPS, the better. However, I fully feel that my original comment is correct and true.
A couple of Data Points:
Almost all UPS manufacturers include a Equipment Protection Warranty. If the UPS's bad waveform fries your equipment they will replace it. See http://www.apcc.com/support/service/equipment_prot ection_policy.cfm for an example. If the pseudo-sinewave that they put out really caused that much grief do you think they would warrant your equipment against damage up to $25,000?
Also, the first thing all modern switching power supplies do is to rectify the incoming AC and then filter it with a capacitor, ending up with about 370 or so volts DC, which it then chops up to produce the lower +- 3.3-12 Volts used in PC's.
The resulting output of the rectifier and Filter Cap (and power factor correcttion, EMI/RFI filtering, etc. etc. etc.) is virtually identical regardless of the input waveform - whether sine or pseudo-sine. I would have to do some nasty math to determine which waveform would be better - my guess is that it would be a toss up.
For a more technical information than you probably ever wanted to know about switching power supplies, I wholehartedly recommend the ON Semiconductor SWITCHMODE Power Supply Reference Manual at http://www.onsemi.com/pub/Collateral/SMPSRM-D.PDF
I'll also stand by my statement about motors. I'll restate to make myself more clear: Switchmode Power Supplies and UPS's get along just fine. Anything else you might have problems with.
As a general rule, if you are using just electronic devices, about any UPS should be fine.
I personally have had great luck with the APC brand, and as a general rule, I won't buy anything else. Your mileage may vary.
Where you run into problems is where you start trying to run traditional "appliances". Fridges, Air Conditioners, Heaters, Microwaves, etc. etc.
Most low-end UPS's (such as the APC Back-UPS) put out a pseudo sine wave, where as the more expensive ones (APC Smart-UPS for instance) put out a "real" sine wave. In theory the "real" sine wave models should work for even the fridge if there is enough wattage available, however, I wouldn't try it without taking to the UPS manufacturer first.
Essentially the difference between the real sine wave and the pseudo one is that the real sine wave is the standard "smooth" sine wave you'd expect to see by plotting the sine function on a graph.
The pseudo version is basically a modified square wave. The power is off (at zero) for a while, then at full positive power, then off, then at full negative power and then back to off, repeat. The ratio between on and off is set up so that the average voltage is the same as a real sign wave, and that the peak voltage is also identical.
This works for almost 100% of the electronics out there. Quite frankly, a switching power supply or even an old fashioned transformer supply doesn't really care about the waveform as long as the voltage is in spec.
The reason why some other loads do is that the waveform itself is important to the operation of the device. For instance, an AC motor actually operates by taking advantage of the reversing voltage to cause rotation. In addition, most inductive loads such as motors, etc. can cause spikes back into the UPS which may either blow the UPS up or cause it's regulation circuit grief.
In short, if you're just wanting to run the electronics, just use any old UPS. If you're wanting to run applicances, well, good luck!
OSPF and RIPv2 are both classless. OSPF has been the internal routing protocol of choice (along with IS-IS and EIGRP in special circumstances) for quite a while. Plus, all of these support variable length subnet masks, which basically means that you can cut up say a Class C into different sized non-overlapping chunks and it will work.
RIPv1 has problems with (if I recall correctly) advertising routes not on an even octet boundary. I would have to look at the spec, but as far as I'm concerned you shouldn't use RIP at all in a "real" network. I cringe when I'm forced to use RIP to get link-state information from dialup hardware, but I think I've about got those eliminated from my network at least:)
RFC1918 addresses can only be used in a few circumstances.
These can be summarized as follows:
If packets from the IP address will never reach the public internet without it being re-written (NAT'd) to a public address, then it is ok.
Some ISP's think that it's ok to use RFC1918 addresses on their internal point-to-point links. It is not. The reason why is that many ISP's filter anything coming from or going to a RFC1918 address because they generally are bogus packets anyways. However, if the RFC1918 addresses are used on internet visible interfaces, this causes things to break.
A good example of this is MTU path discovery. Basically this works by sending a packet from point a to point b with the don't fragment bit set. If the packet reaches a router which can't handle a packet of that size, the router sends back an ICMP packet which basically tells the "Discovering" machine that it couldn't forward the packet because it was too big for it's MTU setting. If the IP address of the offending router's interface happens to be an RFC1918 address, then you might never see the ICMP back and as such you will have weird problems going on.
Note: This is also why you shouldn't just filter ICMP packets.
In the case above, it sounds like the ISP is using the 10.0.0.0 address internally. As they also had the customer using the 10.0.0.0 address range, this could get weird really fast.
Let me qualify this with that some of this information might be dated. I worked for The State of Montana, Department of Administration, ISD (Information Services Division) about 5-6 years ago. This information is based on my recollection of the perceptions I had at the time and information I've heard since.
For the non-montanan's out there, ISD is the part of our state government who has responsiblity for running the state's phone, video, and data networks, and has broad discretionary powers over what is done state-wide. Generally, they have the power to set standards for such things as Word Processing, SpreadSheet, Email, Database, Network Operating systems, etc. Agencies are generally required to follow their lead. Or, in some cases they are allowed to go off on their own but that generally requires an act of god.
The standard desktop machine for the State of Montana is a PC Compatible of some sort. When I was there you had a choice between a Dell and I think DEC, perhaps IBM also.
It sounds like you have had compelling reason in the past to use Macs for your work. Compelling enough that the purchase was permitted. However, that can't compel ISD to permit their connection to the state network.
I suspect the real reason behind this is simple. ISD isn't funded from the General Fund (at least to the largest extent). This means that almost 100% of their revenue stream comes from the agencies they serve. In the past, this has been in the form of a per-pc "tax" on each machine connected to the network. For this you (at least 5 years ago) got the network connection and everything that went with it. This included email and everything else. The figure of $40/pc/month comes to mind but I could be off by a lot, and it might have been per year, but that figure seems too low.
In any case, let's assume they permit you to connect the Mac's to the network. Let's assume there aren't any problems and you don't yelp much if at all. Then everything is great and everything is happy.
But, let's assume you can't make them work. Who is going to be responsible. Traditionally, ISD has helped with these types of issues, but I can say that I suspect that there aren't that many (if any) Mac experts on staff.
Add to that the complication of you perhaps needing to connect to the state mainframe. They will have to support a whole new set of applications on those macs.
If you want Novell services, they will have to deal with namespace issues on the servers you are on.
If you want Email, they will have to get you some sort of Outlook client for a MAC and then figure out why it doesn't work.
And so forth and so forth.
To boil this down a bit, I suspect the real reason is that the potential hassles of having 3 Macs on the network far outweight the benefits. Note that I am NOT saying that the Macs will be a problem.
There is one last thing that I'm going to add here. I would recommend you not rock the boat too much, as what might happen is that you would end up converted to the PC world. Right now, you have it good- basically you're in the driver's seat as far as hardware and software selection. Once you end up on the PC platform, ISD makes those decisions for you.
Speaking from experience, in a lot of rural america, the cost of broadband service is higher because it costs more for the ISP to obtain the service.
I am the technical geek for an ISP. We provide broadband service to our customers via DSL and Wireless. While we have no problems providing a 11mb/s pipe to a customer, filling that pipe gets really expensive really fast, on the order of $10,000 per month. In order for us to recover just the bandwidth cost if we charged $30/month would be over 300 customers. This comes out to be a 24x7 average of 36.6kb/s per customer.
Fortunately, most customers don't average that much, but all it takes is a couple customers running napster to suck down $10k worth of bandwidth, and they are paying $60 for it.
So, maybe to get back to the point, most broadband ISP's have to implement some sort of rate control in order to prevent a couple of customers from taking everyone else's bandwidth. We have in the past done some controls where the customer could suck down x megabytes at a high rate, and then they had a 56k cooling off period before they could continue.
The moral of this is that before you go looking for the cheap ISP which is charging you $19.95 for 7mb/s of bandwidth, remember that it doesn't take many bad users to financially kill the ISP.
I have the equivalent to the v-chip technology turned on on my DishNetwork receivers (both of them) even though we don't have any kids. I don't particularly WANT to see movies/shows with certain types of content, and since I'm a channel flipper, more often than not you run across one of these.
So, I have it turned on to acceptable levels and then when it pops up I can then override it if I want to. But it's a nice way to help prevent some of the crud from ending up in my face.
I think this is a good technology if used right. I don't think that using it as an end-all be-all filter to decide what your kids would be watching is a good idea, but at least it gives you an idea of what type of show it is, so you can be informed.
Slashdot Mirror
This is what I tell most of our customers when they ask about lightning: "If your antenna is directly hit you're pretty much screwed". (Acutally this might be a good place for an appropriate goatse.cx link to illustrate how badly screwed).
I then go on to say that 99.9% of the damage is actually not caused by a direct hit. In fact, the purpose of most "lightning arrestors" is really to drain/discharge the static an antenna picks up.
This also applies to Power/Phone/Satellite TV, etc. etc. etc.. If lightning hits the pole outside your house, you probably will loose equipment. My personal experience is that even if the stuff doesn't immediately fail, you will have ongoing problems with anything exposed to that level of problem. Yes I've seen it.
That said, you can protect yourself in most less extreme cases. Unplugging EVERYTHING is always the best option but in reality isn't really an option for most people. The path I take is to go buy the best surge suppressor and/or ups that you can find. I personally prefer APC's. Most, if not All APC units include an equipment replacement guarantee so if you do take a direct hit you're covered. Remember to supress EVERYTHING. The power line, the phone cord, the satellite antenna cable plugged into the satellite receiver attached to the same power strip, etc. etc. etc. Lan surge supressors are highly recommended, especially if you go anywhere near outside with the cables, or to a "non protected" hub or similar.
Generally for the protection warranty to be effective you must make sure everything is protected or the warranty is void.
Hmmm.. I'm sure there's something else I wanted to add, but I'm not sure what, so I guess I'll quit rambling :)
And remember, off-site backup is always a great idea...
--
--
- The lowest rate for US Cards which the AVS (Address verification system) information matches what is on the cardholder's bank system.
- A slightly higher rate for US cards which the AVS doesn't match.
- A even higher rate (actually several different rates) for various international transactions.
Note that the difference (at least on my bill) is on a per-transaction basis, but that doesn't mean that other processors do something different.The difference in cost is only a percent or two, but it can really add up.
I also suspect part of the problem is that companies are very hesitant to ship to an address that doesn't pass the AVS check, and I know for a fact that most international banks don't provide AVS information.
What a pairgain (and there are other equivalents) does is allow the phone company to put two or more lines on a single pair of copper. A lot of these (the non-digitial ones) actually use the high-frequency part of the wire (where DSL lives) for the second line. Thus, it would be impossible to provide DSL across these.
Add to the fact that there really isn't a copper pair between point a and b for both customers. Even if you could put dsl and pairgain on a pair, only one of the customers would likely be able to use it, unless you do something funky like line sharing, etc.
I was on a contract quite a while back where there were quite a few days where I had to find something to keep busy.
I learned perl. I had been hearing lots and lots of good things about perl and just hadn't had the time to learn it. I went out and got the O'Reilly book Learning Perl which I went through in about 3 days. Has been worth it's weight in gold ever since then. In fact, It saved my butt several times over this past weekend when I was doing a mail server conversion. I can't tell you how many scripts I hacked together to do this conversion or that one.
Your cup of tea might not be perl, but there's lots of other things to learn. There are also online courses you can take. Why not let your employer pay you for the time you spend getting a better education?
Of course, in my example, it was doubly sweet - it was a certain 3 letter government agency which was paying me $50/hour to sit there :).
---
As far as Palm vs WinCE goes, I'll take the PalmOS any day....
I'd buy some palm stock as soon as it dropped to the floor because of this news :).
These are built from standard components: Specifically an intel CA810EAL motherboard ($141.44), Low Profile RAM (Kingmax PC150) ($101/512MB stick), Standard Floppy drive ($10), Thermaltake Low Profile Fan ($8), Standard IDE hard drive ($100ish depending on size), an a FCPGA CPU (Celeron 700's are $77). The case I buy from one of my suppliers for $179, but you can get them for about $225ish on the street.
The only gotchas are that you need to make sure that you use low profile memory and a low profile fan designed for a 1U case, but besides that it all just works.
You can also do dual-processor units, if you really need the CPU, but from your post, it doesn't sound like you're doing anything CPU intensive. The Motherboard mentioned above is a favorite of the "rackmounters" as it has built on Video AND an Intel Pro100 Ethernet card, so you don't even need to waste the 1 PCI slot you are able to get in a 1U case. (Note: There are some 1U cases which will let you use two pci cards, but they are few and far between)
I think what you will find however, is that the sun hardware doesn't really seem all that fast compared to the intel stuff. Besides that, you probably HAVE the spare components lying around if something fails.
------
This is real perl. Not VBScript. I have it running on my FreeBSD box. I'm using standard Perl Modules, for which there is one for about anything under the sun.
As for code size, I can't really argue one way or another. Speaking as a perl programmer, I'm not sure how you can get much smaller code-wise than a lot of perl scripts. From what I could see PHP was just perl with a slightly different (weird) syntax.
I fully agree with you, however, "real" VBScript-based ASP sucks. And is difficult to write, and so on and so forth.
I'm just used to using perl to do everything under the sun, and if I can do my web pages in perl in a "php-like" fashion it's a good thing.
I find it very quick to program in. But again I've literally written megabytes of Perl scripts over the last 2-3 years, and I don't particulary want to learn PHP. If I didn't know perl, I might be inclined to look at PHP.
---
It appears there are three main types. Those which replace the existing atx supply, those which Plug into an PCI Slot and those which fit into a drive bay.
-----------------
--
This is kinda cool :)
--
The main problem I see is that it is a) no longer currently developed and b) platform-limited. However, it is a great product.
I'd switch if I could find another search engine which would do simple things like phrase/near searching, fielded searches, etc., etc., etc.,. The main problem is that most of the search engines are good for doing web-like searches where you don't need a lot of control over the search. Perhaps some of the other readers will be able to help.
I've thought several times about just writing a new search engine. Then I think about what is really involved..... :)
Can you say popping ears? Seriously, With that much height difference, I wonder if there will be health problems. I know that going from sea level to about 5000 feet is a noticible oxygen difference. Try going up 3000+ feet in 2 mins...
Most disposables just use 35mm film. Depending on the camera, they might need to be reloaded in a darkroom, but there are some which do not.
You might want to dig through the results of This google search for more details.
Heck, if this encourages you, why don't you get one and rip it open and let us know what you find?
Perhaps the authors will update it to insult^H^H^H^H^H^H er... emulate whatever new help system microsoft has come up with.
perl -Mself -e'$year++';
Now If I can just remember to increment my internal year counter next year :)...
Considering there were only 50 HTTP servers at the beginning of 1993 (7 years ago). When the ISP I still am on the board of directors for and do a lot of the techincal work for started in the 4th quarter of 1994 (see the registration for mt.net), we didn't even install web server software as we didn't see the need.
Besides, any server which had been up this long would have been rooted 3-4 times, subject to untold Denial of Service attacks, and would be generally unusable.
The phrase "I turned it off and back on to fix it" for a server which has been up for years usually brings cringes to most novell people.
The cause of the effect of drives not spinning back up is simple. While they're spinning, the head collects junk. When you turn the drive off, the head parks and the spindle stops spinning, and the junk on the head sticks to the platters, which in a lot of cases won't spin back up. There is also the issue of the bearings sticking and not restarting.
The trick that almost everyone learns at some point is that the data can be recovered from these drives occasionally (actually quite often) by getting another hard drive ready and then somehow getting the drive spinning. My favorite approach is to freeze the hard drive. Yep. The freezer overnight. If you don't believe me see http://www.internetvalue.com/onsite/200ways.htm
I've also used quite a few of the other methods in here. IF you can get the drive spinning, it will usually work long enough to get at least the data you want off of it.
Let me prefix this with I fully agree that the closer you can get to a True Sine Wave UPS, the better. However, I fully feel that my original comment is correct and true.
A couple of Data Points:
Almost all UPS manufacturers include a Equipment Protection Warranty. If the UPS's bad waveform fries your equipment they will replace it. See http://www.apcc.com/support/service/equipment_prot ection_policy.cfm for an example. If the pseudo-sinewave that they put out really caused that much grief do you think they would warrant your equipment against damage up to $25,000?
Also, the first thing all modern switching power supplies do is to rectify the incoming AC and then filter it with a capacitor, ending up with about 370 or so volts DC, which it then chops up to produce the lower +- 3.3-12 Volts used in PC's. The resulting output of the rectifier and Filter Cap (and power factor correcttion, EMI/RFI filtering, etc. etc. etc.) is virtually identical regardless of the input waveform - whether sine or pseudo-sine. I would have to do some nasty math to determine which waveform would be better - my guess is that it would be a toss up.
For a more technical information than you probably ever wanted to know about switching power supplies, I wholehartedly recommend the ON Semiconductor SWITCHMODE Power Supply Reference Manual at http://www.onsemi.com/pub/Collateral/SMPSRM-D.PDF
I'll also stand by my statement about motors. I'll restate to make myself more clear: Switchmode Power Supplies and UPS's get along just fine. Anything else you might have problems with.
I personally have had great luck with the APC brand, and as a general rule, I won't buy anything else. Your mileage may vary.
Where you run into problems is where you start trying to run traditional "appliances". Fridges, Air Conditioners, Heaters, Microwaves, etc. etc.
Most low-end UPS's (such as the APC Back-UPS) put out a pseudo sine wave, where as the more expensive ones (APC Smart-UPS for instance) put out a "real" sine wave. In theory the "real" sine wave models should work for even the fridge if there is enough wattage available, however, I wouldn't try it without taking to the UPS manufacturer first.
Essentially the difference between the real sine wave and the pseudo one is that the real sine wave is the standard "smooth" sine wave you'd expect to see by plotting the sine function on a graph. The pseudo version is basically a modified square wave. The power is off (at zero) for a while, then at full positive power, then off, then at full negative power and then back to off, repeat. The ratio between on and off is set up so that the average voltage is the same as a real sign wave, and that the peak voltage is also identical.
This works for almost 100% of the electronics out there. Quite frankly, a switching power supply or even an old fashioned transformer supply doesn't really care about the waveform as long as the voltage is in spec.
The reason why some other loads do is that the waveform itself is important to the operation of the device. For instance, an AC motor actually operates by taking advantage of the reversing voltage to cause rotation. In addition, most inductive loads such as motors, etc. can cause spikes back into the UPS which may either blow the UPS up or cause it's regulation circuit grief.
In short, if you're just wanting to run the electronics, just use any old UPS. If you're wanting to run applicances, well, good luck!
RIPv1 has problems with (if I recall correctly) advertising routes not on an even octet boundary. I would have to look at the spec, but as far as I'm concerned you shouldn't use RIP at all in a "real" network. I cringe when I'm forced to use RIP to get link-state information from dialup hardware, but I think I've about got those eliminated from my network at least :)
These can be summarized as follows:
If packets from the IP address will never reach the public internet without it being re-written (NAT'd) to a public address, then it is ok.
Some ISP's think that it's ok to use RFC1918 addresses on their internal point-to-point links. It is not. The reason why is that many ISP's filter anything coming from or going to a RFC1918 address because they generally are bogus packets anyways. However, if the RFC1918 addresses are used on internet visible interfaces, this causes things to break.
A good example of this is MTU path discovery. Basically this works by sending a packet from point a to point b with the don't fragment bit set. If the packet reaches a router which can't handle a packet of that size, the router sends back an ICMP packet which basically tells the "Discovering" machine that it couldn't forward the packet because it was too big for it's MTU setting. If the IP address of the offending router's interface happens to be an RFC1918 address, then you might never see the ICMP back and as such you will have weird problems going on.
Note: This is also why you shouldn't just filter ICMP packets.
In the case above, it sounds like the ISP is using the 10.0.0.0 address internally. As they also had the customer using the 10.0.0.0 address range, this could get weird really fast.
For the non-montanan's out there, ISD is the part of our state government who has responsiblity for running the state's phone, video, and data networks, and has broad discretionary powers over what is done state-wide. Generally, they have the power to set standards for such things as Word Processing, SpreadSheet, Email, Database, Network Operating systems, etc. Agencies are generally required to follow their lead. Or, in some cases they are allowed to go off on their own but that generally requires an act of god.
The standard desktop machine for the State of Montana is a PC Compatible of some sort. When I was there you had a choice between a Dell and I think DEC, perhaps IBM also.
It sounds like you have had compelling reason in the past to use Macs for your work. Compelling enough that the purchase was permitted. However, that can't compel ISD to permit their connection to the state network.
I suspect the real reason behind this is simple. ISD isn't funded from the General Fund (at least to the largest extent). This means that almost 100% of their revenue stream comes from the agencies they serve. In the past, this has been in the form of a per-pc "tax" on each machine connected to the network. For this you (at least 5 years ago) got the network connection and everything that went with it. This included email and everything else. The figure of $40/pc/month comes to mind but I could be off by a lot, and it might have been per year, but that figure seems too low.
In any case, let's assume they permit you to connect the Mac's to the network. Let's assume there aren't any problems and you don't yelp much if at all. Then everything is great and everything is happy.
But, let's assume you can't make them work. Who is going to be responsible. Traditionally, ISD has helped with these types of issues, but I can say that I suspect that there aren't that many (if any) Mac experts on staff.
Add to that the complication of you perhaps needing to connect to the state mainframe. They will have to support a whole new set of applications on those macs.
If you want Novell services, they will have to deal with namespace issues on the servers you are on.
If you want Email, they will have to get you some sort of Outlook client for a MAC and then figure out why it doesn't work.
And so forth and so forth.
To boil this down a bit, I suspect the real reason is that the potential hassles of having 3 Macs on the network far outweight the benefits. Note that I am NOT saying that the Macs will be a problem.
There is one last thing that I'm going to add here. I would recommend you not rock the boat too much, as what might happen is that you would end up converted to the PC world. Right now, you have it good- basically you're in the driver's seat as far as hardware and software selection. Once you end up on the PC platform, ISD makes those decisions for you.
I am the technical geek for an ISP. We provide broadband service to our customers via DSL and Wireless. While we have no problems providing a 11mb/s pipe to a customer, filling that pipe gets really expensive really fast, on the order of $10,000 per month. In order for us to recover just the bandwidth cost if we charged $30/month would be over 300 customers. This comes out to be a 24x7 average of 36.6kb/s per customer.
Fortunately, most customers don't average that much, but all it takes is a couple customers running napster to suck down $10k worth of bandwidth, and they are paying $60 for it.
So, maybe to get back to the point, most broadband ISP's have to implement some sort of rate control in order to prevent a couple of customers from taking everyone else's bandwidth. We have in the past done some controls where the customer could suck down x megabytes at a high rate, and then they had a 56k cooling off period before they could continue.
The moral of this is that before you go looking for the cheap ISP which is charging you $19.95 for 7mb/s of bandwidth, remember that it doesn't take many bad users to financially kill the ISP.
So, I have it turned on to acceptable levels and then when it pops up I can then override it if I want to. But it's a nice way to help prevent some of the crud from ending up in my face.
I think this is a good technology if used right. I don't think that using it as an end-all be-all filter to decide what your kids would be watching is a good idea, but at least it gives you an idea of what type of show it is, so you can be informed.