The only problem I see with the PDA approach is the keyboard size. If you're going to do serious writing, I would think that you would want a standard size keyboard, which puts you back in the realm of 12" notebooks. Personally, I would prefer something like an IBM Thinkpad X series, since you get extremely light weight (as low as 2.6 pounds I believe), and long battery life (up to 8 hours on main battery, probably more like 6 with heavy writing). Older models can be found cheaply on eBay, and you still have all the power of a laptop, just in a thin, lightweight package. I haven't used the 12" Powerbooks, but if you're an Apple person, that would be the obvious choice, though the battery won't last as long. IANAW, but I've done 8 hours of programming work on my old Thinkpad T23 (with an extra ultrabay battery) before, and even the T series is light enough that carrying it around is no burden.
Not a bad solution, but the ingress traffic from P2P software will mostly circumvent this, unless the problem is outbound traffic from the offending user. This is where FreeBSD's pipes and integration with ipfw come in handy. IPFW is stateful, so for each outbound connection that should be limited, the response can be forced through the same limits (though the ipfw man pages suggest using separate pipes with larger queues, a single pipe with a small queue size works better in my opinion). If the rule that caught the outbound connection is something like: ipfw pipe 7 bw 300Kbit/s ipfw add 2100 pipe 7 all from any to any dst-port 80 setup keep-state
and one of the first rules is something like: ipfw add 100 check-state
then the responses to the packets must flow through the same pipe, limiting traffic in both directions. If QoS for all packets is important, and you don't want to deal with set bandwidth, you could use FreeBSD's queues, which are worst-case fair-weighted fair queues, or you can use a queue for a specific pipe (for queueing traffic to a limited-bandwidth pipe). Read through the man page for ipfw, specifically the traffic shaper portion, basically anything needed to solve this sort of problem is already available there.
Because after you've told the tenth person, your time tracking them down, talking to them, and making sure they comply has been worth more than the traffic shaper. One person may cause the problem today, but three more may start next week. Plus, you have to police them if you don't put a shaper in, which also costs you time/money.
One other thing, if you don't want to limit on a host-by-host basis, you could do it by type of service. Say you allocate 80% of your available bandwidth to common web, instant messaging, mail, and DNS traffic, and the remaining 20% for everything else. Just watch your tcpdump/ethereal/etc. logs for about a week to see the normal behavior (and the abuses). This way, the normal, non-abusive services are quick, while the unknown/abusive services are limited, which has a side benefit of discouraging improper use. Hell, if you can lock down the most abused ports, set the pipe they go through to 2400bps, and see how many people still use them in a week.
Here's the problem though, have you seen a P2P client that has a "no, don't use my entire bandwidth, I want to download at 2400bps" option? If people download anything, their system will attempt to move packets at the fastest speed possible, and one heavy user can affect all others. It doesn't matter who the user is today, the original poster wants a solution to the problem tomorrow. A DSL line is not that fast, so chances are pretty good that if one user downloads something large, they could max out the bandwidth, and if 20 all download at the same time (Windows Updates, hopefully), it's pretty much a coin flip for any of them to work. Windows is especially bad at limiting itself to available bandwidth, since it retries packets too often, and 20 machines waiting on bandwidth just means 20 machines retrying packets over and over again. Multiple Windows machines on limited bandwidth are actually quite capable of DoSing themselves, especially at lower (10Mbps) network speeds, or through hubs (you will have more collisions than actual traffic). This is why limiting traffic as it leaves the last switch before the router works well, machines are limited as they go out, and can be told by the QoS engine of the limiting hardware to slow down.
Or FreeBSD, we use our firewall box where I work, and use the traffic shaping portion of ipfw2 (man pages, ipfw at www.FreeBSD.org) to limit bandwidth to certain hosts. FreeBSD allows you to add a rule that passes all traffic through either a pipe or queue (pipe is what you want), set the bandwidth, size of the backlog queue, and monitor usage of the pipes. If you set it up as a transparent bridge (see the advanced network topics in the FreeBSD Handbook at www.FreeBSD.org), you won't even have to change host settings. This way, you can limit traffic on an individual (or group) basis, monitor usage, and just drop the box between the main switch and the dsl router, turn it on, and pretty much forget it (especially if you don't allow remote access to the firewall, except maybe ssh or a VPN).
The same can of course be done with Linux, but in my (though somewhat limited to my place of work) experience, FreeBSD's traffic shaper is a bit more reliable, and much easier to set up (it's all in the handbook). In our case, that box is a transparent bridge, accessible only via ssh or from the inside interfaces, with three NICs, one for the outside router, one for the inside public systems, and a third with private addresses, where natd (man natd, also integrated with ipfw via FreeBSD's divert sockets) translates the private addresses as they go out of one of the other two interfaces. We also run nagios (network monitor), etherape (looks cool when you see the traffic real-time on a GUI), and poptop (MSCHAPv2 capable VPN server), along with IDS logging via ipfw and tcpdump/ethereal, all on an old Duron we had laying around collecting dust.
In all, our Firewall/VPN/IDS/Traffic Shaper/Network monitor cost us about $250 in hardware, and two day's labor. I saw a similar product (though in a nice 1U rackmount case) listed for $6000 at CDW, so whatever you do, you can't go wrong with Linux or FreeBSD on cheaper hardware, unless your time is worth a few thousand dollars an hour.
Actually, yes, I do think it would have been the same. Whether intentional or not, 9/11 gave the highest levels of government the ability to grab more power, and they all did. Republican or Democrat, doesn't matter, both sides approved PATRIOT easily, as well as several other broad-reaching bills (Sarbanes-Oxley after the accounting scandals, for instance). Gore might not have invaded Iraq, or maybe he would have, but that's not the important part. The government didn't have to invade Iraq to take away our rights, they just did it as a side note. Clinton didn't invade Iraq, but he did bomb them, so what's the difference? He obviously thought that bombing them would solve whatever problem he had (which was probably public opinion, not Iraq). Whatever Clinton's true reasons were, it did a good job of distracting the media from what HE was doing.
Both parties in the US are corrupt, in fact probably all governments around the world are corrupt, but at least in some countries, public officials are cheaper. Does it really matter who is in the White House? Probably not. Al Gore would have signed PATRIOT just as quickly as Bush did, and he would have put on the same "Hunt for Al Queda" dog-and-pony show as Bush has, even going to Iraq, so long as it made him look good. Politicians care about their money, careers, power, family, food, personal goals, golf games, favorite type of toilet paper, the constitution, and their constituents, in that order.
But who do you vote for? In most elections, there are zero "good" candidates, it's always picking the lesser of the two evils. So why waste the time? You can't vote for an outsider, they won't win, and the two major parties will both cause more harm than good. You'll either be taxed to death, lose your job and starve, be killed by terrorists, or be killed because the government says you ARE a terrorist. Hell, Janet Reno already ate the bill of rights, and Ashcroft is burning the constitution, so we now have an elected dictatorship.
Tinfoil hat note: My theory is that the government knew about 9/11 before it happened, possibly even directly provoked it, just to get things like the PATRIOT act passed, and distract people from what their true intentions were. It's an old political tactic (think British parliament vs. royal families), just with a new spin. Want to take away your citizen's rights, make them think they need some of them taken away for protection from someone else.
To paraphrase Microsoft's old slogan, "What basic human rights do you want us to violate today?"
For cheaper, smaller units, you are absolutely right. UPS manufacturers want to sell multiple units over a period of time, not just one reliabile system. However, at the high end (not companies, but products), there is more of a focus on reliability and proper charging. We have a nice UPS for the original poster's purposes in our server room. It uses 12 car-sized batteries, and is packaged as a two-cabinet system, with the batteries in the lower cabinet, and a big-ass switch on the upper cabinet (as well as the charging/protection/filtering/backup systems, just that the switch is the most noticeable feature). We have had that UPS for about 4 years now, purchased used at auction from a bankrupt local.COM, and have frequent power outages, and that UPS has never failed. We also have several APC 2200s, which periodically need new batteries, just as described by the original poster.
Check your local auctions, and switch to the big hardware, you won't regret it, it probably won't cost much, and it will probably save you money within two years. I'm not advocating running copper bus bars for 9 servers, but something in a mid-size UPS should work perfectly (mid-size being from about the size of an office copier to a full 19" rack cabinet, yes, there are MUCH bigger systems available, you should have seen the ones at that auction [ours was the smallest one, they did have bus bars in their server room]).
He didn't say what business it was. What if it's a Linux business? Then it would be important to move. Or maybe, like most of us here, he feels strongly enough about the issue to take his toys and play elsewhere.
What, you mean companies that take security seriously, like Diebold? Oh wait, their ATMs had problems with MSBlast... Maybe they told you they haven't had an incident, and maybe they even believe that themselves, but I seriously doubt that it is true. True, a good sysadmin can cut those numbers significantly with firewalls, IDSs, and locking down users, but a good sysadmin also spends more time waking up in the middle of the night worried about the next Windows exploit, than the next Linux/BSD/etc exploit. Hell, I'm tired of getting Code Red/MSBlast/Slammer/.../... attacks on my FreeBSD firewall. They won't work, but the fact that such stupid errors existed means I have an extra 5000 packets a day taking up bandwidth.
The problem isn't always administrators, though. What can you do if there is a known exploit without a patch, and the service is a critical one? You can turn off RPC (at least you probably can, depending on your needs), but you can't turn off your company's mail and web services. Poor system administration is the biggest problem, yes, but the lack of code auditing and slow patch response time with Windows makes a Windows sysadmin less effective.
That's not even taking into account the difference in business models between Windows and Unices. Windows networks are generally based on fat clients that could operate as a separate host (you could log in to the local machine, not through a domain, other machines place too much trust in their peers, and we all know what physical access to a console means), while the Unices generally have a client/server architecture, with a single network-mounted storage volume. To patch a Windows network, you have to patch each machine (whether automated patch programs are used or not), while patching a Unix network generally means updating the server alone. Things like Winterms and Terminal Services change this, but Microsoft will kill you with licensing costs (You pay about $120 for the user on the server, $50 or so for the OS on the winterm [CE], and $100 or more for the terminal services license, which you will have to pay again if you upgrade), and performance will suffer (much more overhead for the server to host a windows session). We had winterms where I work for a while, and they weren't worth it, and neither is Windows. One experienced Unix admin may cost more than one Windows admin, but the Unix admin can handle four or five times the number of users, since there is not really an extra machine for each user, there is basically only a limit to the number of users each machine can support, which is usually around 50-100, depending on the application. Supporting 100 Windows clients by yourself is hard work, 100 boot from network Unix boxes is easy.
The real problem with Windows is the lack of source. If I have a problem with by BSD or Linux boxes, or just don't like the way something is handled, I can change it. (For example, I have changed portions of libalias and natd on my FreeBSD box to show translation information in my logs) If you aren't in the Fortune 50, Microsoft won't care that you want something different, and Linus, Theo, and the FreeBSD team probably don't either, but at least with OSS you can do it yourself, and if you want something done right....
For large companies, the first statement is absolutely true. Sarbanes-Oxley comes to mind. If the company is publicly traded, document retention policies need to be strictly enforced, and allowing even administrative personnel to modify or delete files becomes a huge liability. The law sucks, but denying you administrative access to your machine could save you $20 million and/or 20 years in prison. Deal with it.
If you are trying to find a way to maintain productivity levels of experienced Unix staff on Windows, forget it, it is impossible. Anyone that types over 10wpm will be able to do more with a Unix system, since experienced Unix people tend to prefer CLI to GUI, and you can't click that fast. As for books to read, the UI isn't your problem, it's the difference in opinion on Administration. You would really have to know what systems are in place (Active Directory being a major one), how administrative tasks are divided, and what tasks will need to be done by your people on a daily/weekly/monthly basis. You most likely don't need to know everything, and what you do largely depends on what the company expects from you. Unix is not just an operating system, it's a business model, and if the new company doesn't fit that model, you probably aren't in a position to change that. In other words, you probably don't need a book/training on Windows, you need a book/training on your new employer, which hopefully will be provided to you when your department is absorbed. There is really no point in studying something that you don't know you will use.
There used to be a cpio-like archiver called apio, that was designed for those types of situations. Of course, that might not be much help for non-unix systems (unless you plan on running in Cygwin), but I remember having great success with it for the old QIC tapes, which were in my experience the worst backup medium for important data ever (better to have no backup than think you have a good one, but have a dead tape)
True, if the data is important, don't touch it, send it to the professionals. If it's just your porn collection, break out the sledgehammer, at best, you'll get your data back, at worst, and most likely, you'll have fun hitting a drive with a hammer.
That's a bad idea. What if a security patch breaks the software you run? Do you want all 200 of your machines to be fsck'd when you come in Monday morning? Personally, I don't like being at work to fix a bad patch at 5:00 AM, before 50 people need their systems to work at 6:00. I'm still sleeping then. Keep a clean system with your software on it, install patches, test them, then update the other machines. Vulnerabilities like ASN.1 (where exploits are published the next day) really hurt in this situation, but it's the only way to do it right.
You can't blindly install software, you have to test it. What if windowsupdate.microsoft.com got compromised, or if an attacker played man-in-the-middle? Your entire network would be fubared in 5 minutes. In addition, what about the times where a critical patch doesn't show up on Windows Update (this happens a lot). Windows Update has been proven to be broken before, and I had a few machines that didn't show the ASN.1 patch as available, but were not patched. Manually installing Windows patches sucks, I prefer cvsup;make buildworld;make installworld, and I prefer only having 2 security advisories so far this year (FreeBSD, of which 0 affected my systems).
You're absolutely right, no OS is secure. The only defense OSS has is that patches can be released quickly, while Microsoft took 200 days to fix ASN.1 (for which a similar problem was found and fixed very quickly in the BSDs and Linux last March).
How many large companies/organizations running Windows where hacked last year? The point is, most companies/organizations don't report IT security breaches, certainly not like GNU did. If you have a high-profile company, and someone with enough skill wants to, you WILL be hacked eventually, regardless of your choice of OS. Most blackhats don't have the skill level that the GNU attack took, and even that probably could have been prevented, but there is a tradeoff between high security and convenience, and a 0day exploit is hard to stop, unless you can stay awake 24/7 and process incoming ethernet frames in your head fast enough to determine their intent before forwarding them.
I personally would rather be attacked once a month and know of the attack instantly than be attacked once a year and not know. Security starts at the power outlet, once you plug a machine in, you're vulnerable. (And no, you can't have my netblock range)
Running as root (or Administrator) is not a security problem for people who visit trusted sites only, do not execute email attachments, don't run 'rm -rf *' or deltree from the root directory, and keep their systems patched.
For the average windows user (like your grandparents), who don't know how to update their systems, will open any email, and browse to random sites, it's not very safe. Running on a non-superuser account means that only your user files may be compromised by a malicious or buggy program, not the entire system (unless there is a bug in code that runs in kernel mode, like system calls, or much of Windows code that runs under the SYSTEM account).
Look at web servers, for instance. IIS runs from the LOCALSYSTEM account by default, while apache runs as nobody by default. Which is more secure? If IIS never had a flaw, it wouldn't matter, but when it does, any exploit that allows remote execution of code (most of them) runs with full priviledges, while the same vulnerability grants only read access priviledges to certain (already public) files under apache. It's the same thing with users. If you can trust them never to make a mistake or execute malicious code, they can run with full priviledges, but if you can't (most of the time), maybe you shouldn't give them the ability to destroy files or add/remove hardware.
I agree, statistically speaking, Windows machines must be the most vulnerable, since they have the largest installed base. What would be interesting to see would be a report of how many systems were attacked, and how many of those attacks were successful (both automated and manual attacks). But even that wouldn't mean that the winner was the most secure, it would mean that the administrators for those systems did a good job.
What they should show is the number of security advisories for the core platform (not counting 3rd party software like PCAnywhere, sendmail, etc) in the last year (which would be Windows SAs > Linux SAs > BSD SAs), the time to patch a known issue (Windows > BSD > Linux most likely), and the seriousness of the SA. That would define the most secure OS when properly administered. If you could compare that to out-of-the-box security settings, which would require splitting the BSDs, Windows versions, and Linux distributions, then you would have the most secure out-of-box OS (probably OpenBSD, FreeBSD, MacOSX, SuSE, RH, NetBSD, Mandrake, then the various Windows OSs at the worst [distributions like Gentoo and Debian would be hard to determine out-of-box settings for, and any Windows fans should note that no other OS comes with file sharing turned on by default]).
What this study does show, however, is that Linux system administrators have done a poor job. Of course, I don't know the sample sizes for each OS, but assuming they are all the same (which seems reasonable, considering that they didn't count automated attacks, which make up the majority of Windows attacks).
Basically, that makes the study useless, except that the code maturity of the BSDs show through, and the lack of experience with at least a small percentage of Linux SysAdmins, and a general lack of control by Windows SysAdmins. Do this with automated attacks included, and the numbers normalized, and with experienced SysAdmins across the board, and the report will mean something. BSD and Linux are both quickly patched and easily hardened, Windows is the opposite, but can still be hardened, depending on your needs. Just remember, a vulnerability only matters when someone knows of an exploit, and your machine allows them in. Border firewalls, IDSs, and a good SysAdmin will save 99% of the problems.
Yeah, grab some coffee and a cigarette, but I hear you. Don't automatically patch systems that you don't manage. For in-house software that's been tested, let the clients pull updates automatically (once approved and made available), but for software distributed to other companies, let the user/administrator choose whether or not to pull updates, ideally so that a few machines can test your patches first.
Also, don't be like Microsoft. If you're going to have updates, make sure that every machine that is eligible for the update will see that an update is available. I found two Windows 2000 machines today that had all patches installed according to Windows Update, but didn't have the ASN.1 patch installed. Installing patches manually blows, almost as much as having broken patches installed automatically. Think about it: If microsoft forced patches on Windows systems, and they made a mistake, 95% of the internet would be knocked out. (Then again, at least I wouldn't have had the 3 Code Red I [yes, the original] attacks from China wasting my bandwidth on my BSD box yesterday)
Hot-pluggable keyboards are quite handy for servers.
WTF are you talking about? You unplug things from your servers? Hot-pluggable keyboards are useless for servers, because your business is either big enough to have a KVM switch on your servers (preferably a nice pull out rack-mounted LCD), or small enough to be able to afford 5 minutes of downtime while you swap keyboards.
As a side note, you could buy a new PS/2 keyboard and mouse for less than $10, or buy the adapters to convert them from USB to PS/2.
I agree, which is why I didn't say the "L" models, just a simple LaserJet 4 or 5. Even a 4MP would work, but they never seemed as solid to me as the 4/5s... They're bulky, but built to last, and have great quality print.
As for the 4100, we've had some problems with toner leakage on them (toner ends up all over the fuser after about 5,000 pages), so watch your pages.
It also depends on what you are doing, and more importantly, how good their techs are. Companies like Cisco do a good job of phone support (but you will be bounced around the world as shifts change), and have experienced techs who seem to be interested in helping. Companies like (insert local/cell phone company here), on the other hand, usually have techs who don't know what they're doing, don't understand spoken english well, and don't care about your problem, since you're locked into a contract that guarantees nothing but profits for them. For those companies, chat/email works better.
By far, though, the best type of tech support for non-emergencies is what DEC (Digital Equipment Corp., now part of HP-Compaq) and many other large companies used to do (and many medical hardware companies still do). You pay for a service contract, you call with a hardware problem, and they have an experienced tech on the next flight to you, carrying all the parts they need. It's expensive, but very effective.
Or even better, find an old HP LaserJet 4 or 5 at you local county auction, you can usually pick one up for about $5, with a toner cartridge in it. Other than that, try pricewatch for used printers, as long as it is a quality printer, you should have no problems with reliability.
That's why, unless you use a compiler farm with 4+ machines, "emerge openoffice-bin" is probably a better idea. You can change this with "emerge unmerge openoffice", then emerge the openoffice-bin package.
Slashdot Mirror
The only problem I see with the PDA approach is the keyboard size. If you're going to do serious writing, I would think that you would want a standard size keyboard, which puts you back in the realm of 12" notebooks. Personally, I would prefer something like an IBM Thinkpad X series, since you get extremely light weight (as low as 2.6 pounds I believe), and long battery life (up to 8 hours on main battery, probably more like 6 with heavy writing). Older models can be found cheaply on eBay, and you still have all the power of a laptop, just in a thin, lightweight package. I haven't used the 12" Powerbooks, but if you're an Apple person, that would be the obvious choice, though the battery won't last as long. IANAW, but I've done 8 hours of programming work on my old Thinkpad T23 (with an extra ultrabay battery) before, and even the T series is light enough that carrying it around is no burden.
Not a bad solution, but the ingress traffic from P2P software will mostly circumvent this, unless the problem is outbound traffic from the offending user. This is where FreeBSD's pipes and integration with ipfw come in handy. IPFW is stateful, so for each outbound connection that should be limited, the response can be forced through the same limits (though the ipfw man pages suggest using separate pipes with larger queues, a single pipe with a small queue size works better in my opinion). If the rule that caught the outbound connection is something like:
ipfw pipe 7 bw 300Kbit/s
ipfw add 2100 pipe 7 all from any to any dst-port 80 setup keep-state
and one of the first rules is something like:
ipfw add 100 check-state
then the responses to the packets must flow through the same pipe, limiting traffic in both directions. If QoS for all packets is important, and you don't want to deal with set bandwidth, you could use FreeBSD's queues, which are worst-case fair-weighted fair queues, or you can use a queue for a specific pipe (for queueing traffic to a limited-bandwidth pipe). Read through the man page for ipfw, specifically the traffic shaper portion, basically anything needed to solve this sort of problem is already available there.
Because after you've told the tenth person, your time tracking them down, talking to them, and making sure they comply has been worth more than the traffic shaper. One person may cause the problem today, but three more may start next week. Plus, you have to police them if you don't put a shaper in, which also costs you time/money.
One other thing, if you don't want to limit on a host-by-host basis, you could do it by type of service. Say you allocate 80% of your available bandwidth to common web, instant messaging, mail, and DNS traffic, and the remaining 20% for everything else. Just watch your tcpdump/ethereal/etc. logs for about a week to see the normal behavior (and the abuses). This way, the normal, non-abusive services are quick, while the unknown/abusive services are limited, which has a side benefit of discouraging improper use. Hell, if you can lock down the most abused ports, set the pipe they go through to 2400bps, and see how many people still use them in a week.
Here's the problem though, have you seen a P2P client that has a "no, don't use my entire bandwidth, I want to download at 2400bps" option? If people download anything, their system will attempt to move packets at the fastest speed possible, and one heavy user can affect all others. It doesn't matter who the user is today, the original poster wants a solution to the problem tomorrow. A DSL line is not that fast, so chances are pretty good that if one user downloads something large, they could max out the bandwidth, and if 20 all download at the same time (Windows Updates, hopefully), it's pretty much a coin flip for any of them to work. Windows is especially bad at limiting itself to available bandwidth, since it retries packets too often, and 20 machines waiting on bandwidth just means 20 machines retrying packets over and over again. Multiple Windows machines on limited bandwidth are actually quite capable of DoSing themselves, especially at lower (10Mbps) network speeds, or through hubs (you will have more collisions than actual traffic). This is why limiting traffic as it leaves the last switch before the router works well, machines are limited as they go out, and can be told by the QoS engine of the limiting hardware to slow down.
Or FreeBSD, we use our firewall box where I work, and use the traffic shaping portion of ipfw2 (man pages, ipfw at www.FreeBSD.org) to limit bandwidth to certain hosts. FreeBSD allows you to add a rule that passes all traffic through either a pipe or queue (pipe is what you want), set the bandwidth, size of the backlog queue, and monitor usage of the pipes. If you set it up as a transparent bridge (see the advanced network topics in the FreeBSD Handbook at www.FreeBSD.org), you won't even have to change host settings. This way, you can limit traffic on an individual (or group) basis, monitor usage, and just drop the box between the main switch and the dsl router, turn it on, and pretty much forget it (especially if you don't allow remote access to the firewall, except maybe ssh or a VPN).
The same can of course be done with Linux, but in my (though somewhat limited to my place of work) experience, FreeBSD's traffic shaper is a bit more reliable, and much easier to set up (it's all in the handbook). In our case, that box is a transparent bridge, accessible only via ssh or from the inside interfaces, with three NICs, one for the outside router, one for the inside public systems, and a third with private addresses, where natd (man natd, also integrated with ipfw via FreeBSD's divert sockets) translates the private addresses as they go out of one of the other two interfaces. We also run nagios (network monitor), etherape (looks cool when you see the traffic real-time on a GUI), and poptop (MSCHAPv2 capable VPN server), along with IDS logging via ipfw and tcpdump/ethereal, all on an old Duron we had laying around collecting dust.
In all, our Firewall/VPN/IDS/Traffic Shaper/Network monitor cost us about $250 in hardware, and two day's labor. I saw a similar product (though in a nice 1U rackmount case) listed for $6000 at CDW, so whatever you do, you can't go wrong with Linux or FreeBSD on cheaper hardware, unless your time is worth a few thousand dollars an hour.
Actually, yes, I do think it would have been the same. Whether intentional or not, 9/11 gave the highest levels of government the ability to grab more power, and they all did. Republican or Democrat, doesn't matter, both sides approved PATRIOT easily, as well as several other broad-reaching bills (Sarbanes-Oxley after the accounting scandals, for instance). Gore might not have invaded Iraq, or maybe he would have, but that's not the important part. The government didn't have to invade Iraq to take away our rights, they just did it as a side note. Clinton didn't invade Iraq, but he did bomb them, so what's the difference? He obviously thought that bombing them would solve whatever problem he had (which was probably public opinion, not Iraq). Whatever Clinton's true reasons were, it did a good job of distracting the media from what HE was doing.
Both parties in the US are corrupt, in fact probably all governments around the world are corrupt, but at least in some countries, public officials are cheaper. Does it really matter who is in the White House? Probably not. Al Gore would have signed PATRIOT just as quickly as Bush did, and he would have put on the same "Hunt for Al Queda" dog-and-pony show as Bush has, even going to Iraq, so long as it made him look good. Politicians care about their money, careers, power, family, food, personal goals, golf games, favorite type of toilet paper, the constitution, and their constituents, in that order.
But who do you vote for? In most elections, there are zero "good" candidates, it's always picking the lesser of the two evils. So why waste the time? You can't vote for an outsider, they won't win, and the two major parties will both cause more harm than good. You'll either be taxed to death, lose your job and starve, be killed by terrorists, or be killed because the government says you ARE a terrorist. Hell, Janet Reno already ate the bill of rights, and Ashcroft is burning the constitution, so we now have an elected dictatorship.
Tinfoil hat note: My theory is that the government knew about 9/11 before it happened, possibly even directly provoked it, just to get things like the PATRIOT act passed, and distract people from what their true intentions were. It's an old political tactic (think British parliament vs. royal families), just with a new spin. Want to take away your citizen's rights, make them think they need some of them taken away for protection from someone else.
To paraphrase Microsoft's old slogan, "What basic human rights do you want us to violate today?"
For cheaper, smaller units, you are absolutely right. UPS manufacturers want to sell multiple units over a period of time, not just one reliabile system. However, at the high end (not companies, but products), there is more of a focus on reliability and proper charging. We have a nice UPS for the original poster's purposes in our server room. It uses 12 car-sized batteries, and is packaged as a two-cabinet system, with the batteries in the lower cabinet, and a big-ass switch on the upper cabinet (as well as the charging/protection/filtering/backup systems, just that the switch is the most noticeable feature). We have had that UPS for about 4 years now, purchased used at auction from a bankrupt local .COM, and have frequent power outages, and that UPS has never failed. We also have several APC 2200s, which periodically need new batteries, just as described by the original poster.
Check your local auctions, and switch to the big hardware, you won't regret it, it probably won't cost much, and it will probably save you money within two years. I'm not advocating running copper bus bars for 9 servers, but something in a mid-size UPS should work perfectly (mid-size being from about the size of an office copier to a full 19" rack cabinet, yes, there are MUCH bigger systems available, you should have seen the ones at that auction [ours was the smallest one, they did have bus bars in their server room]).
He didn't say what business it was. What if it's a Linux business? Then it would be important to move. Or maybe, like most of us here, he feels strongly enough about the issue to take his toys and play elsewhere.
What, you mean companies that take security seriously, like Diebold? Oh wait, their ATMs had problems with MSBlast... Maybe they told you they haven't had an incident, and maybe they even believe that themselves, but I seriously doubt that it is true. True, a good sysadmin can cut those numbers significantly with firewalls, IDSs, and locking down users, but a good sysadmin also spends more time waking up in the middle of the night worried about the next Windows exploit, than the next Linux/BSD/etc exploit. Hell, I'm tired of getting Code Red/MSBlast/Slammer/.../... attacks on my FreeBSD firewall. They won't work, but the fact that such stupid errors existed means I have an extra 5000 packets a day taking up bandwidth.
The problem isn't always administrators, though. What can you do if there is a known exploit without a patch, and the service is a critical one? You can turn off RPC (at least you probably can, depending on your needs), but you can't turn off your company's mail and web services. Poor system administration is the biggest problem, yes, but the lack of code auditing and slow patch response time with Windows makes a Windows sysadmin less effective.
That's not even taking into account the difference in business models between Windows and Unices. Windows networks are generally based on fat clients that could operate as a separate host (you could log in to the local machine, not through a domain, other machines place too much trust in their peers, and we all know what physical access to a console means), while the Unices generally have a client/server architecture, with a single network-mounted storage volume. To patch a Windows network, you have to patch each machine (whether automated patch programs are used or not), while patching a Unix network generally means updating the server alone. Things like Winterms and Terminal Services change this, but Microsoft will kill you with licensing costs (You pay about $120 for the user on the server, $50 or so for the OS on the winterm [CE], and $100 or more for the terminal services license, which you will have to pay again if you upgrade), and performance will suffer (much more overhead for the server to host a windows session). We had winterms where I work for a while, and they weren't worth it, and neither is Windows. One experienced Unix admin may cost more than one Windows admin, but the Unix admin can handle four or five times the number of users, since there is not really an extra machine for each user, there is basically only a limit to the number of users each machine can support, which is usually around 50-100, depending on the application. Supporting 100 Windows clients by yourself is hard work, 100 boot from network Unix boxes is easy.
The real problem with Windows is the lack of source. If I have a problem with by BSD or Linux boxes, or just don't like the way something is handled, I can change it. (For example, I have changed portions of libalias and natd on my FreeBSD box to show translation information in my logs) If you aren't in the Fortune 50, Microsoft won't care that you want something different, and Linus, Theo, and the FreeBSD team probably don't either, but at least with OSS you can do it yourself, and if you want something done right....
Sorry, I believe it was afio
For large companies, the first statement is absolutely true. Sarbanes-Oxley comes to mind. If the company is publicly traded, document retention policies need to be strictly enforced, and allowing even administrative personnel to modify or delete files becomes a huge liability. The law sucks, but denying you administrative access to your machine could save you $20 million and/or 20 years in prison. Deal with it.
If you are trying to find a way to maintain productivity levels of experienced Unix staff on Windows, forget it, it is impossible. Anyone that types over 10wpm will be able to do more with a Unix system, since experienced Unix people tend to prefer CLI to GUI, and you can't click that fast. As for books to read, the UI isn't your problem, it's the difference in opinion on Administration. You would really have to know what systems are in place (Active Directory being a major one), how administrative tasks are divided, and what tasks will need to be done by your people on a daily/weekly/monthly basis. You most likely don't need to know everything, and what you do largely depends on what the company expects from you. Unix is not just an operating system, it's a business model, and if the new company doesn't fit that model, you probably aren't in a position to change that. In other words, you probably don't need a book/training on Windows, you need a book/training on your new employer, which hopefully will be provided to you when your department is absorbed. There is really no point in studying something that you don't know you will use.
There used to be a cpio-like archiver called apio, that was designed for those types of situations. Of course, that might not be much help for non-unix systems (unless you plan on running in Cygwin), but I remember having great success with it for the old QIC tapes, which were in my experience the worst backup medium for important data ever (better to have no backup than think you have a good one, but have a dead tape)
True, if the data is important, don't touch it, send it to the professionals. If it's just your porn collection, break out the sledgehammer, at best, you'll get your data back, at worst, and most likely, you'll have fun hitting a drive with a hammer.
That's a bad idea. What if a security patch breaks the software you run? Do you want all 200 of your machines to be fsck'd when you come in Monday morning? Personally, I don't like being at work to fix a bad patch at 5:00 AM, before 50 people need their systems to work at 6:00. I'm still sleeping then. Keep a clean system with your software on it, install patches, test them, then update the other machines. Vulnerabilities like ASN.1 (where exploits are published the next day) really hurt in this situation, but it's the only way to do it right.
You can't blindly install software, you have to test it. What if windowsupdate.microsoft.com got compromised, or if an attacker played man-in-the-middle? Your entire network would be fubared in 5 minutes. In addition, what about the times where a critical patch doesn't show up on Windows Update (this happens a lot). Windows Update has been proven to be broken before, and I had a few machines that didn't show the ASN.1 patch as available, but were not patched. Manually installing Windows patches sucks, I prefer cvsup;make buildworld;make installworld, and I prefer only having 2 security advisories so far this year (FreeBSD, of which 0 affected my systems).
You're absolutely right, no OS is secure. The only defense OSS has is that patches can be released quickly, while Microsoft took 200 days to fix ASN.1 (for which a similar problem was found and fixed very quickly in the BSDs and Linux last March).
How many large companies/organizations running Windows where hacked last year? The point is, most companies/organizations don't report IT security breaches, certainly not like GNU did. If you have a high-profile company, and someone with enough skill wants to, you WILL be hacked eventually, regardless of your choice of OS. Most blackhats don't have the skill level that the GNU attack took, and even that probably could have been prevented, but there is a tradeoff between high security and convenience, and a 0day exploit is hard to stop, unless you can stay awake 24/7 and process incoming ethernet frames in your head fast enough to determine their intent before forwarding them.
I personally would rather be attacked once a month and know of the attack instantly than be attacked once a year and not know. Security starts at the power outlet, once you plug a machine in, you're vulnerable. (And no, you can't have my netblock range)
Running as root (or Administrator) is not a security problem for people who visit trusted sites only, do not execute email attachments, don't run 'rm -rf *' or deltree from the root directory, and keep their systems patched.
For the average windows user (like your grandparents), who don't know how to update their systems, will open any email, and browse to random sites, it's not very safe. Running on a non-superuser account means that only your user files may be compromised by a malicious or buggy program, not the entire system (unless there is a bug in code that runs in kernel mode, like system calls, or much of Windows code that runs under the SYSTEM account).
Look at web servers, for instance. IIS runs from the LOCALSYSTEM account by default, while apache runs as nobody by default. Which is more secure? If IIS never had a flaw, it wouldn't matter, but when it does, any exploit that allows remote execution of code (most of them) runs with full priviledges, while the same vulnerability grants only read access priviledges to certain (already public) files under apache. It's the same thing with users. If you can trust them never to make a mistake or execute malicious code, they can run with full priviledges, but if you can't (most of the time), maybe you shouldn't give them the ability to destroy files or add/remove hardware.
I agree, statistically speaking, Windows machines must be the most vulnerable, since they have the largest installed base. What would be interesting to see would be a report of how many systems were attacked, and how many of those attacks were successful (both automated and manual attacks). But even that wouldn't mean that the winner was the most secure, it would mean that the administrators for those systems did a good job.
What they should show is the number of security advisories for the core platform (not counting 3rd party software like PCAnywhere, sendmail, etc) in the last year (which would be Windows SAs > Linux SAs > BSD SAs), the time to patch a known issue (Windows > BSD > Linux most likely), and the seriousness of the SA. That would define the most secure OS when properly administered. If you could compare that to out-of-the-box security settings, which would require splitting the BSDs, Windows versions, and Linux distributions, then you would have the most secure out-of-box OS (probably OpenBSD, FreeBSD, MacOSX, SuSE, RH, NetBSD, Mandrake, then the various Windows OSs at the worst [distributions like Gentoo and Debian would be hard to determine out-of-box settings for, and any Windows fans should note that no other OS comes with file sharing turned on by default]).
What this study does show, however, is that Linux system administrators have done a poor job. Of course, I don't know the sample sizes for each OS, but assuming they are all the same (which seems reasonable, considering that they didn't count automated attacks, which make up the majority of Windows attacks).
Basically, that makes the study useless, except that the code maturity of the BSDs show through, and the lack of experience with at least a small percentage of Linux SysAdmins, and a general lack of control by Windows SysAdmins. Do this with automated attacks included, and the numbers normalized, and with experienced SysAdmins across the board, and the report will mean something. BSD and Linux are both quickly patched and easily hardened, Windows is the opposite, but can still be hardened, depending on your needs. Just remember, a vulnerability only matters when someone knows of an exploit, and your machine allows them in. Border firewalls, IDSs, and a good SysAdmin will save 99% of the problems.
Yeah, grab some coffee and a cigarette, but I hear you. Don't automatically patch systems that you don't manage. For in-house software that's been tested, let the clients pull updates automatically (once approved and made available), but for software distributed to other companies, let the user/administrator choose whether or not to pull updates, ideally so that a few machines can test your patches first.
Also, don't be like Microsoft. If you're going to have updates, make sure that every machine that is eligible for the update will see that an update is available. I found two Windows 2000 machines today that had all patches installed according to Windows Update, but didn't have the ASN.1 patch installed. Installing patches manually blows, almost as much as having broken patches installed automatically. Think about it: If microsoft forced patches on Windows systems, and they made a mistake, 95% of the internet would be knocked out. (Then again, at least I wouldn't have had the 3 Code Red I [yes, the original] attacks from China wasting my bandwidth on my BSD box yesterday)
Hot-pluggable keyboards are quite handy for servers.
WTF are you talking about? You unplug things from your servers? Hot-pluggable keyboards are useless for servers, because your business is either big enough to have a KVM switch on your servers (preferably a nice pull out rack-mounted LCD), or small enough to be able to afford 5 minutes of downtime while you swap keyboards.
As a side note, you could buy a new PS/2 keyboard and mouse for less than $10, or buy the adapters to convert them from USB to PS/2.
I agree, which is why I didn't say the "L" models, just a simple LaserJet 4 or 5. Even a 4MP would work, but they never seemed as solid to me as the 4/5s... They're bulky, but built to last, and have great quality print.
As for the 4100, we've had some problems with toner leakage on them (toner ends up all over the fuser after about 5,000 pages), so watch your pages.
It also depends on what you are doing, and more importantly, how good their techs are. Companies like Cisco do a good job of phone support (but you will be bounced around the world as shifts change), and have experienced techs who seem to be interested in helping. Companies like (insert local/cell phone company here), on the other hand, usually have techs who don't know what they're doing, don't understand spoken english well, and don't care about your problem, since you're locked into a contract that guarantees nothing but profits for them. For those companies, chat/email works better.
By far, though, the best type of tech support for non-emergencies is what DEC (Digital Equipment Corp., now part of HP-Compaq) and many other large companies used to do (and many medical hardware companies still do). You pay for a service contract, you call with a hardware problem, and they have an experienced tech on the next flight to you, carrying all the parts they need. It's expensive, but very effective.
Or even better, find an old HP LaserJet 4 or 5 at you local county auction, you can usually pick one up for about $5, with a toner cartridge in it. Other than that, try pricewatch for used printers, as long as it is a quality printer, you should have no problems with reliability.
That's why, unless you use a compiler farm with 4+ machines, "emerge openoffice-bin" is probably a better idea. You can change this with "emerge unmerge openoffice", then emerge the openoffice-bin package.