whole disk encryption as a class generally works OK but opens a whole new set of problems; MBR corruption might mean you lose the whole disk; performance overhead is NOT going to be 1% (unless you do virtually no I/O) but the 10-30% that it will be is usually a good tradeoff vs. the confidential data you're trying to protect.
The real reason for the policy is that should a hard drive/laptop/whatever be lost, if it's encrypted no notification is required by law. If it's not encrypted, then you need to prove that the drive didn't contain any PII, which is hard to do since it's no longer available for forensic evaluation.
I suggest you ensure you application is decidedly incompatible with PGP whole disk (BSD? Oddball version of Linux? Custom library in your code that crashes the computer when it detects PGP?) so the IT dept simply can't ram it down your throat. This will buy time, perhaps until hardware mfg's have hardware-level encryption that eliminates the unfortunate performance and compatibility aspects of whole disk encryption.
PS: I've looked at whole disk encryption from a variety of vendors including utimaco, pointsec, and pgp -- they all pretty much work, but assume a generic windows PC running generic apps. Once you move out of that I suspect their support will thin out quickly and IT will abandon the effort.
I've discovered it just doesn't mesh with who I am as a person. Some people just love to be assholes and make work for others, say "no" a lot, and generally piss people off. I didn't realize that a lot of what "security" comes down to is that sort of thing. From the outside, all of the research, hacking, break-ins, forensics, etc. is extremely interesting. But when it comes to the day-to-day responsibility for millions of peoples PII, corporate oversight, depositions, audits, etc. Oy.
Or maybe you're drawn to the "big brother" side of things -- monitoring email, web usage, AUP violations, etc. Maybe you're a natural voyeur. But when you're instrumental in getting someone fired for minor infractions of AUP, and have to live with the knowledge that you're somehow partly to blame...
Some people become cops because they get off on having authority and like to throw their weight around. Others like to build things. If you're a builder, then don't get into security, since your job in security is to prevent, control, and destroy, in the hope of protecting your assets.
Someday you'll have an epiphany: "No matter what I do, how hard I try, something, somewhere, will get screwed up and there will be a breach or suspected breach. And when that happens, the ensuing investigation will make me and/or my department look like fools and destroy whatever is left of my career".
Then you get out of security. Maybe you'll be less lucky and almost die from a bleeding ulcer first, like me.
So if you want to do security, great. Enjoy. I'm going back to the low-stress world of system administration. I might lots of midnight calls, but the healing needs to begin.
I meant 4 drives for the entire shelf, 2 on each side. So you're getting the capacity of 10 disks instead of 14. With better raid controllers, or (in this case) a better filesystem, you'd get the capacity of 12 disks per shelf.
Since each disk is quite large, you're talking around 1TB wasted.
I'd guess ZFS would be pretty handy for those of us with a lot of XRaid enclosures -- use them as JBOD with ZFS handled by the mac host, and you eliminate all sorts of annoying problems (e.g., each xraid is actually two separate arrays of 7 drives each, so raid-5 with a hot spare means losing 4-drives worth of capacity on each shelf.)
Also as xraid transitions (it must, right?) from 3.5" SATA to 2.5" SATA or SAS drives, they'll be able to pack 10 into a 1U enclosure, or 40 into a 4U enclosure. If the host supports ZFS then they could probably skimp on the "raid controller" contained in this hypothetical xraid replacment even more than they already have.
Screen the calls with an answering machine, or at least callerID. When you see the trouble user calling, WAIT. Listen to their message, don't call them back right away. The time you wait varies from person to person, so you'll need to expiriment. Start with 24 hours, then add 24 hours at a time.
Call them back "sorry I didn't get back to you, it's been crazy here" (probably the truth anyway).
Eventually they will realize that calling you will not get an emergency response, and they will either figure it out in that time, or find someone else to call.
This is easier to do with annoying people from church, PTA, your AA meeting, etc. Since you sold them the system to begin with, this is a bad technique to encourage repeat business. So make sure you want to get out of the small-build business before you use it. Remember -- "just get a dell" or "just get a mac" are perfectly reasonable responses to the "what kind of computer should I get?" rather than "I'll build the perfect system for you".
Now if we could just get them involved with a religious cult that would inspire them to all commit mass suicide... Roach kool-aid anyone?
Extensive research, measured in kilos
on
Cocaine Biosensor
·
· Score: 4, Funny
It ended up taking about 68 kilos of cocaine to finally nail down the winning formula, reported biochemist George Placky. "We put in a lot of long nights, in fact we frequently would stay in the lab for 72 hours straight." "The team worked so hard we tried to accomodate them wherever possible." Indeed the lab is awash with stereo equipment, couches, and large screen TVs.
Univeristy officials confirmed the long nights. Security guard Paul Costas remakred "Yeah, those guys were going at it for days on end. I helped them smuggle chicks into their parti..ahh *research*."
"We feel that with another couple of years we will have similar sensors for crystal meth, heroin, and extasy." said Dr. Placky, who is currently applying for federal grants to fund the research, as well as provide sufficient quantities of the substances for thorough research.
Radio controlled pacemaker? This will have to show up on 'CSI' pretty soon then. Would _you_ want a pacemaker that someone could re-program wirelessly? Say someone sitting behind you on the train/bus/subway/airplane?
Or maybe they use some strong security... WEP anyone? Now that would be freaking hilarious. Security Alert: "We regret to inform you that your heart implant is vulnerable to a wireless attack. The risk is mitigated by the fact the attacker must be within 5 feet of you, and own a laptop with special radio components that can be built using plans freely available on the internet for about $26 in parts.Please do not worry, sue us, or be surprised if you die when your enemies figure this out."
If you don't mind a hardware 'solution', look for a 'limiter' at your local musicians equipment shop. I got one about 10 years ago (rocksonics -- appear to be out of business now) which works great. I think it cost about $100, plus I needed some 1/4" -->RCA adapters.
On the other hand there's lots of software that does the same thing -- main benefit of hardware is you could hook it up in front of some powered speakers and use any audio source (e.g. plain cd player).
One other problem with limiting/compression is that cheaper ones aren't sensitive to frequency -- a big bass beat will kick in the limiter more than it should in terms of perceived loudness. In general you can fiddle with it and get it to sound reasonably good while eliminating 'the loud bits'.
Sure, some foreign government or well-funded industrial spy may use a $10,000 or $100,000 tool. Ditto for someone who has a cracked version of a commercial tool.
It seems much more likely that the black-hat types are either going to use freely available tools, or will write their own custom jobs before they will submit to using some fancy point-and-click GUI that attempts to hide complexity from them (even if their employer provides it). It's dangerous to assume that no one will attack you with commercial tools. I think it's valid to assume the probability of getting scanned by nmap and nessus is much higher than being scanned by some expensive proprietary tools. Therefore it makes sense to test with the free tools to ensure that the most common scenarios are covered.
I got a powerbook 667MHz a while back and it's still going strong. Best laptop I've ever had. Sure the 1.2GHz or faster models are a bit snappier, but it's totally usable.
The difference between a 1.2/1.3GHz today vs. a 1.4/1.5GHz in a month or two (which is what it'd be given the inevitable shipping delays for the newest gear from Apple, even if something happened next week) will be minimal at best. Of course if they 'bump' includes more RAM or a bigger hard drive...
Anyway, main point is it doesn't much matter. Even when a G5 laptop ships it's going to be a new model and the existing ibook/powerbook series has been around for a while so expect more bugs to work out. I'd recommend waiting for the second model to sport a G5, so you're not stuck working out Apples overheating, loud fan, poor battery life, failing mainboard first attempt at a G5 (not that any of that has happened before:)
Also, for those who question moving from *linux* to a mac, even when you have the skill to get something working doesn't mean you have the patience or time to devote to it. Having stuff "just work" without any trouble is a very nice selling point for Mac hardware and OS X. Much better even than Windows, the nominal target market for most add-ons. Besides, it *is* unix, despite the eye candy. I was sold when I shut the lid on my powerbook at work, it snoozed, I opened it at home, and it automatically figured out it was on a different network, switched from the cabled connection to wireless, and was up and running within seconds of opening the lid. Compared to an IBM thinkpad/XP pro machine that takes 45-50 seconds to 'wake up', plus gets easily confused about network connections... It's nice to have stuff just work, and do it unobstrusivley in the background.
One thing we do with 'cat 5' cables is color-code different length cables, so black == 3 feet, green == 7 feet, yellow = 10 feet, orange == 14 feet, red == 25 feet, grayish-white == 50 feet, red with yellow boots == crossover cable. This has been helpful in a number of ways. -- it's unlikely a white cable will be to something else in that cabinet, crossovers are easily identified, longer cables are probably for servers further away from the switch/patch panel/whatever, it provides some color distinction in otherwise monochrome patch panels, it's easy to stock and order cables like this.
One thing I wish we did is have unique serial numbers on both ends of each (and every!) cable. While it's possible to trace cables using the tried-and-true tug-and-feel method, in reality it sucks and printed documentation is difficult to keep in sync with reality.
I've also seen cables color-coded for other purposes, but these haven't worked as well e.g.: one color is for network, another for KVM, another for switch uplinks, etc. This works well until you need a KVM cable, but don't have the right length in the right color so substitute "temporarily", blowing the scheme completely since 'temporary' is a synonym for 'permament' in most datacenters. another example: Use every color available randomly in the hope that there are only so many hot-pink cables with a green stripe in your datacenter making it easier to trace things. In reality this last example doesn't scale well and makes patch panels look really untidy.
As far as what I *think* you were asking, which is whether there is some qualitative difference between cables -- there is. Make sure you get 'certified' cables from a trusted vendor, preferably each one individually tested with the results pasted on a sticker on the (sealed) bag each cable comes in. Also make sure you get 'plenum' cables where necessary to comply with fire codes and just plain common sense. I'd say any permament infrastructure cables (not patch cables) should be plenum whether they are legally required to be or not -- if you have a fire you'd be better off without a few hundred extra pounds of fuel to keep it going. Beyond plenum/pvc and tested cables there isn't much else to stress over -- thank god "Monster" doesn't make patch cables with 24k gold connectors to hoodwink unsuspecting people -- if the cable tests good the rest doesn't matter.
Since the "IE-only" sites are presumably known, set up a sqid proxy that only allows access to those specific sites. Set everyones IE to use the proxy server.
Then to allow access to the wider internet, set up firefox w/out a proxy, or (more secure) firewall off ports 80 and 443 and proxy firefox through a different squid server which allows more-or-less open access.
Note that it's virtually impossible to 'lock down' IE under citrix since you can hit the 'help' menu which has a link to 'web help' which gives you... -- try it and you'll see what I mean. All citrix would do for you is to crap out their entire iE install in one go when there's a problem.
The IBM enterprise SAN device -- shark -- is only able to crank data out at about 35MB/s per disk pack, assuming sole access. When you've got multiple systems hitting one disk pack it drops dramatically from that.
So 80MB/s is more than their disk systems can do anyway, unless you're pulling data from multiple packs.
Seriously. On the java side you get immense complexity, and on the.net side while all of the choices are made for you, there is still a lot of complexity. Either platform requires a lot of tribal knowledge to get started with.
If at all possible look at a PHP web-based front end. The interface can be tricked out with some nice javascript style features (e.g.: google gmail) and keep your back-end database interface open, so you can bundle postgres for free, or they can use oracle/db2/whatever if they want to.
The big win for PHP is time to market -- you can cobble together an app _very_ quickly by avoiding the 3-6 month j2ee/.net learning curve. It also lets you be more price-competitive since you can deploy it on a really inexpensive platform. So if your competition quotes $50,000 which has to include fast servers (.net is just as resource hungry as java), windows licenses, database licenses, and several additional months of development time, you can quote $40,000 and still have a bigger profit margin since you don't have the higher-cost platform.
Make sure to offer a 'reporting' module that is basically a $500 copy of crystal reports with a bunch of reports you've developed -- don't fall into the "I'll roll my own reporting engine" trap.
If 'rich' interfaces are required, don't discount javascript, xul, or even flash -- all of which eliminate the 800-pound gorilla that is.net/java.
One of the big reasons to buy a big system are for it's purported high-availability features, such as raid arrays, hot-swap drives, hot-swap power supplies, hot-add RAM, etc.
Performance is really secondary to availability in a lot of these situations. What happens when you pull a drive from an array or mirror set? How long does it take to rebuild? What happens if you pull 2 drives and put one right back? What happens if you scramble which drives are in which array slot then power on? Can you extend a volume 'on the fly' or do you need to back up to tape, re-create the entire array, and restore your data?
For example, HP/Compaq raid controllers let you replace (one drive at a time) small hard drives with higher capacity drives. Once all of the drives are higher capacity you can go and allocate the rest of the space as a new raid volume. On an RS6000 you'd need to back up to tape, re-do the entire thing, then restore.
Test enterprise features -- connecting disimilar SANs, FC multi-channel failover, pull a power supply, use a space heater to simulate an A/C failure and see at what temp (and for how long) it takes for the system to become unstable.
Disconnect random cables, pull random chips from sockets, see if the on-board diagnostics help you locate the problem.
Disassemble the system and re-assemble it. How many tools did you need? How long did it take? How is the internal build quality? Are you going to cut your hands on sharp edges or is it all nicely laid out and easy to service? (Even if the end-user company won't be servicing it, if service is easier then it will likely be faster as well, shortening outages).
For networking equipment, can you build a 100% fault-tolerant clustered hot-failover system? What extra pieces did you need and how much would it cost? How well does the failover work? Seamless? 1-2 second 'burp'?
Pehaps you don't properly understand the nature of your job.
Find a different job. If you find yourself treating your users like crap because you hate them for being idiots then you're in the wrong line of work. Get some skills and move on to something else, preferably at a different company so you don't have 5-6 hours a day of the same old support calls since users know to come to you.
If you want to keep the job, then be much more proactive. Seek out trouble users and _ask_them_ if they need help. After fixing something call later in the day or the next day and make sure it's still OK. The users will love you and you'll find they (generally) will respect you more. Over time you will go home at night feeling good that you helpd a bunch of people and they really appreciate you.
The negative, punish-the-users, techniques are counterproductive and will lead to simply more stress and eventually getting fired or (if you can't be fired for some bizarre union rule or whatever) everyone wishing you were gone which is just as bad.
FUD: "Open source isn't supported well, or costs more to support"
Reality: "Open source tends to be supported extremely well, but the costs are incurred differently than with commercial software. More expensive is harder to evaluate since commercial stuff tends to be aquisition based + annual maintenance while open source tends to be a combination if in-house expertise, low aquisition cost, possibly higher annual maintenance. It could be a wash or either one could be higher. The difference is that _you_ are in control and can switch (or cancel) support contracts at will. Try that with some commercial product."
FUD: "Linux admins are hard to find"
Reality: "The Linux admins you do find tend to be 10x-100x better technically than the paper-MCSE idiots you'll get for windows admins. This translates to fewer admins needed overall, plus much less ''support'' required since the admins are more self-sufficient. You need to be able to hire people with 2-3 years of ''real'' experience vs. the 5-10 years demanded by most HR departments."
FUD: "Open source may force you to self-support with web searches & mailing lists"
Reality: "Most (99%+) windows problems I've encountered tend to be solved by google or microsoft knowledge base searches. The other 1% we either live with or assign a low-level tech to call and sit on hold waiting for a high-school dropout to read us a script about rebooting. The fact is, most commercial support sucks. Hard. Be glad there are mailing list archives, google searches, etc. to help solve problems. As a bonus, once you've solved the problem you're never forced to upgrade to a new unstable version by the vendor -- you support your own stuff with your own experience coupled with the experience of the community at large."
FUD: "Open source expertise is hard to find"
Reality: "There are a lot of open source projects in a lot of different fields. This is really like saying ''Computer experience is hard to find'' back in the 80s or 90s. The problem is finding experience for the specific product you need. Try finding a ''sagent'' admin to hire (an expensive proprietary ETL tool) -- it's hard because there aren't many people using it. Likewise finding someone with 10 years of Oracle or DB2 is going to be easier than 10 years of MySQL or Postgres, the point of which is that 1: the commercial product may have been around longer and 2: the commercial product from 10 years ago was likely a very different beast than the current product, so the value of 10 years of experience in a specific product is suspect at best. In this case you should be looking for 10 years of RDMBS/SQL experience without regard to the specific products used."
A lot of this seems to be a fundamental phase-shift in IT expertise required hitting the shoals of inadequate HR hiring practices.
I recently read a book "The Visionary Position" which detailed the university of washingtons virtual reality lab and all of the various spin-off companies.
It wasn't a bad book, but they've had these things since the mid-90's -- just hard to find an appropriate market I guess.
We use RT for a lot of things. Not sure what you're trying to accomplish with the P.O. thing, but if it's a workflow (request/approve/deny) then RT can do it.
If you're trying to just print out PO forms then open office or any of the other free spreadsheet programs can do that sort of thing.
This comment is aimed at "production use" -- for "test/development" (non production) machines, please disregard.
While an HP/Compaq "Proliant DL380" at around $5,000 with a 2nd CPU, redundant fans, RAID hard drives, etc. is a _lot_ more expensive than a $1,000 white box with a couple of IDE drives with software RAID, it tends to be worth it. At least in my situation.
I've used white box servers in the past, and they are fine while they work. Once something goes wrong you're sort of on your own to track down the problem, find the original vendor (and your reciept), wait several weeks for waranty repair or (more likely) purchase a new motherboard/power supply/hard drive/whatever to use while you wait for the replacement to come back.
The biggest problem is troubleshooting time. The Compaq servers have excellent integrated logs, diagnostic capabilities, and in general it's easy to isolate what's wrong and if it's a bad part, proprietary though it may be, you generally have it by the next day.
With a white box, you (or your reseller) integrate the system, which _usually_ is OK, but if you get a sometimes-flaky RAM chip, or a bad trace on a motherboard, it's easy to fix by swapping it out, but very time consuming to take the machine apart, replace your best guess, put it together, try it, then repeat. With a "real" server the quality is generally _much_ higher, so you don't get most of these flaky problems in the first place, plus the rack mount cases are designed to keep repair times minimal. You can pop open a DL380 and replace a fan without even shutting the machine down. The power supply can be swapped out without even opening the case (and has a nifty LED on it to indicate if it's got a problem), and If you spring $200 for a redundant power supply you don't even need to shut down first. Ditto for the hard drives.
What it really comes down to are 3 things: 1: Is the service provided worth anything? If not, then why bother doing a server at all? If it is important, how many days a month can the system be unavailable? 2: If the system is worth something, and downtime is not acceptable, can it be clustered (e.g.: DNS server) or is it best done as one machine (e.g.: SQL server)? 3: If it can be clustered (and will be -- many things _can_ be clustered but only at enormous expense), then using crap hardware may be acceptable as long as you have 2 or more running, the failure of 1 is tolerable. If it can't be clustered, then you really need to think about "real" server hardware, penny-wise/pound foolish, and all of that stuff.
Is this something of your own initiative or are you being pressured to do this? If the pressure is on, then you are being set up for failure. If you're forced into it get your resume polished and/or try to set someone else up to take the fall (which is unlikely to work since we're talking about $2-4,000 -- chump change for all but an extremely small business where no one else is around to be blamed).
Explain that a compiler tokenizes input from a high level programming language and produces a parse tree which eventually results in object code, which is then linked to static or dynamic libraries with a linker and loaded into RAM by a loader.
I would then immediately jump into the finer points of data structures and algorithms, for example balanced trees, big O notation, efficiencies of various sort algorithms, red/black trees, etc.
Don't forget to use lots of greek characters. In fact this might be a good time to clear up some abstract programming topics, such as lambda functions, macros (in the lisp sense), continuations, anonymous functions, etc.
Suggest Intercal as a good beginners language.
Whatever demo machine you use, make sure to put a block of dry ice in it and claim it is cooled by liquid nitrogen.
Chances are if they run OpenBSD they will run Linux as well (although why you'd prefer the linux firewall features over the OpenBSD pf firewall escapes me).
If your main goal is lower electrical cost, that might be a good option anyway. If you are willing and technically competent enough to maintain your own box, you should. Othwerise you give up a _lot_ of flexibility (ability to run snort, dsniff, caching proxy, dns, honeypot, etc.).
Sans offers some great security training, which while not a general "Intro to Linux" does provide some very intensive insight into securing Unix/Linux.
Books can be good, but research them carefuly before you plop down $50 for "linux unleashed" or some other crap book.
Some good books to look at: UNIX System Administration Handbook (3rd Edition) by Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein [THE classic Unix admin book, this edition also has some Linux-specific stuff]
Linux Administration Handbook by Evi Nemeth, Garth Snyder, Trent Hein, Trent R. Hein [Similar to the above, but all Linux specific. Get both if you can.]
Many (not all) OReilly books (especially older ones) tend to be excellent references, e.g. DNS and BIND, Learning the vi editor, Sendmail, Practical UNIX and Internet security, Programming Perl, etc.
One problem you may face is that "Linux" in the "I just installed Suse" sense, is much more than Windows. Where in Windows you'd need to cover basic setup, network config, active directory, basic security, and maybe web server config, in Linux you have all of that plus the functional equivalent of SQL server, Visual Studio, dozens of programming languages, Office, etc.
Good luck! It's a fun ride once you get the hang of it.
Slashdot Mirror
whole disk encryption as a class generally works OK but opens a whole new set of problems; MBR corruption might mean you lose the whole disk; performance overhead is NOT going to be 1% (unless you do virtually no I/O) but the 10-30% that it will be is usually a good tradeoff vs. the confidential data you're trying to protect.
The real reason for the policy is that should a hard drive/laptop/whatever be lost, if it's encrypted no notification is required by law. If it's not encrypted, then you need to prove that the drive didn't contain any PII, which is hard to do since it's no longer available for forensic evaluation.
I suggest you ensure you application is decidedly incompatible with PGP whole disk (BSD? Oddball version of Linux? Custom library in your code that crashes the computer when it detects PGP?) so the IT dept simply can't ram it down your throat. This will buy time, perhaps until hardware mfg's have hardware-level encryption that eliminates the unfortunate performance and compatibility aspects of whole disk encryption.
PS: I've looked at whole disk encryption from a variety of vendors including utimaco, pointsec, and pgp -- they all pretty much work, but assume a generic windows PC running generic apps. Once you move out of that I suspect their support will thin out quickly and IT will abandon the effort.
I've discovered it just doesn't mesh with who I am as a person. Some people just love to be assholes and make work for others, say "no" a lot, and generally piss people off. I didn't realize that a lot of what "security" comes down to is that sort of thing. From the outside, all of the research, hacking, break-ins, forensics, etc. is extremely interesting. But when it comes to the day-to-day responsibility for millions of peoples PII, corporate oversight, depositions, audits, etc. Oy.
Or maybe you're drawn to the "big brother" side of things -- monitoring email, web usage, AUP violations, etc. Maybe you're a natural voyeur. But when you're instrumental in getting someone fired for minor infractions of AUP, and have to live with the knowledge that you're somehow partly to blame...
Some people become cops because they get off on having authority and like to throw their weight around. Others like to build things. If you're a builder, then don't get into security, since your job in security is to prevent, control, and destroy, in the hope of protecting your assets.
Someday you'll have an epiphany: "No matter what I do, how hard I try, something, somewhere, will get screwed up and there will be a breach or suspected breach. And when that happens, the ensuing investigation will make me and/or my department look like fools and destroy whatever is left of my career".
Then you get out of security. Maybe you'll be less lucky and almost die from a bleeding ulcer first, like me.
So if you want to do security, great. Enjoy. I'm going back to the low-stress world of system administration. I might lots of midnight calls, but the healing needs to begin.
I meant 4 drives for the entire shelf, 2 on each side. So you're getting the capacity of 10 disks instead of 14. With better raid controllers, or (in this case) a better filesystem, you'd get the capacity of 12 disks per shelf.
Since each disk is quite large, you're talking around 1TB wasted.
I'd guess ZFS would be pretty handy for those of us with a lot of XRaid enclosures -- use them as JBOD with ZFS handled by the mac host, and you eliminate all sorts of annoying problems (e.g., each xraid is actually two separate arrays of 7 drives each, so raid-5 with a hot spare means losing 4-drives worth of capacity on each shelf.)
Also as xraid transitions (it must, right?) from 3.5" SATA to 2.5" SATA or SAS drives, they'll be able to pack 10 into a 1U enclosure, or 40 into a 4U enclosure. If the host supports ZFS then they could probably skimp on the "raid controller" contained in this hypothetical xraid replacment even more than they already have.
Screen the calls with an answering machine, or at least callerID. When you see the trouble user calling, WAIT. Listen to their message, don't call them back right away. The time you wait varies from person to person, so you'll need to expiriment. Start with 24 hours, then add 24 hours at a time.
Call them back "sorry I didn't get back to you, it's been crazy here" (probably the truth anyway).
Eventually they will realize that calling you will not get an emergency response, and they will either figure it out in that time, or find someone else to call.
This is easier to do with annoying people from church, PTA, your AA meeting, etc. Since you sold them the system to begin with, this is a bad technique to encourage repeat business. So make sure you want to get out of the small-build business before you use it. Remember -- "just get a dell" or "just get a mac" are perfectly reasonable responses to the "what kind of computer should I get?" rather than "I'll build the perfect system for you".
Now if we could just get them involved with a religious cult that would inspire them to all commit mass suicide... Roach kool-aid anyone?
It ended up taking about 68 kilos of cocaine to finally nail down the winning formula, reported biochemist George Placky. "We put in a lot of long nights, in fact we frequently would stay in the lab for 72 hours straight." "The team worked so hard we tried to accomodate them wherever possible." Indeed the lab is awash with stereo equipment, couches, and large screen TVs.
Univeristy officials confirmed the long nights. Security guard Paul Costas remakred "Yeah, those guys were going at it for days on end. I helped them smuggle chicks into their parti..ahh *research*."
"We feel that with another couple of years we will have similar sensors for crystal meth, heroin, and extasy." said Dr. Placky, who is currently applying for federal grants to fund the research, as well as provide sufficient quantities of the substances for thorough research.
Radio controlled pacemaker? This will have to show up on 'CSI' pretty soon then. Would _you_ want a pacemaker that someone could re-program wirelessly? Say someone sitting behind you on the train/bus/subway/airplane?
Or maybe they use some strong security... WEP anyone? Now that would be freaking hilarious. Security Alert: "We regret to inform you that your heart implant is vulnerable to a wireless attack. The risk is mitigated by the fact the attacker must be within 5 feet of you, and own a laptop with special radio components that can be built using plans freely available on the internet for about $26 in parts.Please do not worry, sue us, or be surprised if you die when your enemies figure this out."
If you don't mind a hardware 'solution', look for a 'limiter' at your local musicians equipment shop. I got one about 10 years ago (rocksonics -- appear to be out of business now) which works great. I think it cost about $100, plus I needed some 1/4" -->RCA adapters.
On the other hand there's lots of software that does the same thing -- main benefit of hardware is you could hook it up in front of some powered speakers and use any audio source (e.g. plain cd player).
One other problem with limiting/compression is that cheaper ones aren't sensitive to frequency -- a big bass beat will kick in the limiter more than it should in terms of perceived loudness. In general you can fiddle with it and get it to sound reasonably good while eliminating 'the loud bits'.
Sure, some foreign government or well-funded industrial spy may use a $10,000 or $100,000 tool. Ditto for someone who has a cracked version of a commercial tool.
It seems much more likely that the black-hat types are either going to use freely available tools, or will write their own custom jobs before they will submit to using some fancy point-and-click GUI that attempts to hide complexity from them (even if their employer provides it). It's dangerous to assume that no one will attack you with commercial tools. I think it's valid to assume the probability of getting scanned by nmap and nessus is much higher than being scanned by some expensive proprietary tools. Therefore it makes sense to test with the free tools to ensure that the most common scenarios are covered.
I got a powerbook 667MHz a while back and it's still going strong. Best laptop I've ever had. Sure the 1.2GHz or faster models are a bit snappier, but it's totally usable.
:)
The difference between a 1.2/1.3GHz today vs. a 1.4/1.5GHz in a month or two (which is what it'd be given the inevitable shipping delays for the newest gear from Apple, even if something happened next week) will be minimal at best. Of course if they 'bump' includes more RAM or a bigger hard drive...
Anyway, main point is it doesn't much matter. Even when a G5 laptop ships it's going to be a new model and the existing ibook/powerbook series has been around for a while so expect more bugs to work out. I'd recommend waiting for the second model to sport a G5, so you're not stuck working out Apples overheating, loud fan, poor battery life, failing mainboard first attempt at a G5 (not that any of that has happened before
Also, for those who question moving from *linux* to a mac, even when you have the skill to get something working doesn't mean you have the patience or time to devote to it. Having stuff "just work" without any trouble is a very nice selling point for Mac hardware and OS X. Much better even than Windows, the nominal target market for most add-ons. Besides, it *is* unix, despite the eye candy. I was sold when I shut the lid on my powerbook at work, it snoozed, I opened it at home, and it automatically figured out it was on a different network, switched from the cabled connection to wireless, and was up and running within seconds of opening the lid. Compared to an IBM thinkpad/XP pro machine that takes 45-50 seconds to 'wake up', plus gets easily confused about network connections... It's nice to have stuff just work, and do it unobstrusivley in the background.
One thing we do with 'cat 5' cables is color-code different length cables, so black == 3 feet, green == 7 feet, yellow = 10 feet, orange == 14 feet, red == 25 feet, grayish-white == 50 feet, red with yellow boots == crossover cable. This has been helpful in a number of ways. -- it's unlikely a white cable will be to something else in that cabinet, crossovers are easily identified, longer cables are probably for servers further away from the switch/patch panel/whatever, it provides some color distinction in otherwise monochrome patch panels, it's easy to stock and order cables like this.
One thing I wish we did is have unique serial numbers on both ends of each (and every!) cable. While it's possible to trace cables using the tried-and-true tug-and-feel method, in reality it sucks and printed documentation is difficult to keep in sync with reality.
I've also seen cables color-coded for other purposes, but these haven't worked as well e.g.: one color is for network, another for KVM, another for switch uplinks, etc. This works well until you need a KVM cable, but don't have the right length in the right color so substitute "temporarily", blowing the scheme completely since 'temporary' is a synonym for 'permament' in most datacenters. another example: Use every color available randomly in the hope that there are only so many hot-pink cables with a green stripe in your datacenter making it easier to trace things. In reality this last example doesn't scale well and makes patch panels look really untidy.
As far as what I *think* you were asking, which is whether there is some qualitative difference between cables -- there is. Make sure you get 'certified' cables from a trusted vendor, preferably each one individually tested with the results pasted on a sticker on the (sealed) bag each cable comes in. Also make sure you get 'plenum' cables where necessary to comply with fire codes and just plain common sense. I'd say any permament infrastructure cables (not patch cables) should be plenum whether they are legally required to be or not -- if you have a fire you'd be better off without a few hundred extra pounds of fuel to keep it going. Beyond plenum/pvc and tested cables there isn't much else to stress over -- thank god "Monster" doesn't make patch cables with 24k gold connectors to hoodwink unsuspecting people -- if the cable tests good the rest doesn't matter.
Since the "IE-only" sites are presumably known, set up a sqid proxy that only allows access to those specific sites. Set everyones IE to use the proxy server.
Then to allow access to the wider internet, set up firefox w/out a proxy, or (more secure) firewall off ports 80 and 443 and proxy firefox through a different squid server which allows more-or-less open access.
Note that it's virtually impossible to 'lock down' IE under citrix since you can hit the 'help' menu which has a link to 'web help' which gives you... -- try it and you'll see what I mean. All citrix would do for you is to crap out their entire iE install in one go when there's a problem.
The IBM enterprise SAN device -- shark -- is only able to crank data out at about 35MB/s per disk pack, assuming sole access. When you've got multiple systems hitting one disk pack it drops dramatically from that.
So 80MB/s is more than their disk systems can do anyway, unless you're pulling data from multiple packs.
Seriously. On the java side you get immense complexity, and on the .net side while all of the choices are made for you, there is still a lot of complexity. Either platform requires a lot of tribal knowledge to get started with.
.net/java.
If at all possible look at a PHP web-based front end. The interface can be tricked out with some nice javascript style features (e.g.: google gmail) and keep your back-end database interface open, so you can bundle postgres for free, or they can use oracle/db2/whatever if they want to.
The big win for PHP is time to market -- you can cobble together an app _very_ quickly by avoiding the 3-6 month j2ee/.net learning curve. It also lets you be more price-competitive since you can deploy it on a really inexpensive platform. So if your competition quotes $50,000 which has to include fast servers (.net is just as resource hungry as java), windows licenses, database licenses, and several additional months of development time, you can quote $40,000 and still have a bigger profit margin since you don't have the higher-cost platform.
Make sure to offer a 'reporting' module that is basically a $500 copy of crystal reports with a bunch of reports you've developed -- don't fall into the "I'll roll my own reporting engine" trap.
If 'rich' interfaces are required, don't discount javascript, xul, or even flash -- all of which eliminate the 800-pound gorilla that is
One of the big reasons to buy a big system are for it's purported high-availability features, such as raid arrays, hot-swap drives, hot-swap power supplies, hot-add RAM, etc.
Performance is really secondary to availability in a lot of these situations. What happens when you pull a drive from an array or mirror set? How long does it take to rebuild? What happens if you pull 2 drives and put one right back? What happens if you scramble which drives are in which array slot then power on? Can you extend a volume 'on the fly' or do you need to back up to tape, re-create the entire array, and restore your data?
For example, HP/Compaq raid controllers let you replace (one drive at a time) small hard drives with higher capacity drives. Once all of the drives are higher capacity you can go and allocate the rest of the space as a new raid volume. On an RS6000 you'd need to back up to tape, re-do the entire thing, then restore.
Test enterprise features -- connecting disimilar SANs, FC multi-channel failover, pull a power supply, use a space heater to simulate an A/C failure and see at what temp (and for how long) it takes for the system to become unstable.
Disconnect random cables, pull random chips from sockets, see if the on-board diagnostics help you locate the problem.
Disassemble the system and re-assemble it. How many tools did you need? How long did it take? How is the internal build quality? Are you going to cut your hands on sharp edges or is it all nicely laid out and easy to service? (Even if the end-user company won't be servicing it, if service is easier then it will likely be faster as well, shortening outages).
For networking equipment, can you build a 100% fault-tolerant clustered hot-failover system? What extra pieces did you need and how much would it cost? How well does the failover work? Seamless? 1-2 second 'burp'?
Pehaps you don't properly understand the nature of your job.
Find a different job. If you find yourself treating your users like crap because you hate them for being idiots then you're in the wrong line of work. Get some skills and move on to something else, preferably at a different company so you don't have 5-6 hours a day of the same old support calls since users know to come to you.
If you want to keep the job, then be much more proactive. Seek out trouble users and _ask_them_ if they need help. After fixing something call later in the day or the next day and make sure it's still OK. The users will love you and you'll find they (generally) will respect you more. Over time you will go home at night feeling good that you helpd a bunch of people and they really appreciate you.
The negative, punish-the-users, techniques are counterproductive and will lead to simply more stress and eventually getting fired or (if you can't be fired for some bizarre union rule or whatever) everyone wishing you were gone which is just as bad.
FUD: "Open source isn't supported well, or costs more to support"
Reality: "Open source tends to be supported extremely well, but the costs are incurred differently than with commercial software. More expensive is harder to evaluate since commercial stuff tends to be aquisition based + annual maintenance while open source tends to be a combination if in-house expertise, low aquisition cost, possibly higher annual maintenance. It could be a wash or either one could be higher. The difference is that _you_ are in control and can switch (or cancel) support contracts at will. Try that with some commercial product."
FUD: "Linux admins are hard to find"
Reality: "The Linux admins you do find tend to be 10x-100x better technically than the paper-MCSE idiots you'll get for windows admins. This translates to fewer admins needed overall, plus much less ''support'' required since the admins are more self-sufficient. You need to be able to hire people with 2-3 years of ''real'' experience vs. the 5-10 years demanded by most HR departments."
FUD: "Open source may force you to self-support with web searches & mailing lists"
Reality: "Most (99%+) windows problems I've encountered tend to be solved by google or microsoft knowledge base searches. The other 1% we either live with or assign a low-level tech to call and sit on hold waiting for a high-school dropout to read us a script about rebooting. The fact is, most commercial support sucks. Hard. Be glad there are mailing list archives, google searches, etc. to help solve problems. As a bonus, once you've solved the problem you're never forced to upgrade to a new unstable version by the vendor -- you support your own stuff with your own experience coupled with the experience of the community at large."
FUD: "Open source expertise is hard to find"
Reality: "There are a lot of open source projects in a lot of different fields. This is really like saying ''Computer experience is hard to find'' back in the 80s or 90s. The problem is finding experience for the specific product you need. Try finding a ''sagent'' admin to hire (an expensive proprietary ETL tool) -- it's hard because there aren't many people using it. Likewise finding someone with 10 years of Oracle or DB2 is going to be easier than 10 years of MySQL or Postgres, the point of which is that 1: the commercial product may have been around longer and 2: the commercial product from 10 years ago was likely a very different beast than the current product, so the value of 10 years of experience in a specific product is suspect at best. In this case you should be looking for 10 years of RDMBS/SQL experience without regard to the specific products used."
A lot of this seems to be a fundamental phase-shift in IT expertise required hitting the shoals of inadequate HR hiring practices.
You should see the cover. Picture of a woman in a skin-tight suit who appears to be enjoying herself in a naughty fashion.
I recently read a book "The Visionary Position" which detailed the university of washingtons virtual reality lab and all of the various spin-off companies.
It wasn't a bad book, but they've had these things since the mid-90's -- just hard to find an appropriate market I guess.
We use RT for a lot of things. Not sure what you're trying to accomplish with the P.O. thing, but if it's a workflow (request/approve/deny) then RT can do it.
If you're trying to just print out PO forms then open office or any of the other free spreadsheet programs can do that sort of thing.
This comment is aimed at "production use" -- for "test/development" (non production) machines, please disregard.
While an HP/Compaq "Proliant DL380" at around $5,000 with a 2nd CPU, redundant fans, RAID hard drives, etc. is a _lot_ more expensive than a $1,000 white box with a couple of IDE drives with software RAID, it tends to be worth it. At least in my situation.
I've used white box servers in the past, and they are fine while they work. Once something goes wrong you're sort of on your own to track down the problem, find the original vendor (and your reciept), wait several weeks for waranty repair or (more likely) purchase a new motherboard/power supply/hard drive/whatever to use while you wait for the replacement to come back.
The biggest problem is troubleshooting time. The Compaq servers have excellent integrated logs, diagnostic capabilities, and in general it's easy to isolate what's wrong and if it's a bad part, proprietary though it may be, you generally have it by the next day.
With a white box, you (or your reseller) integrate the system, which _usually_ is OK, but if you get a sometimes-flaky RAM chip, or a bad trace on a motherboard, it's easy to fix by swapping it out, but very time consuming to take the machine apart, replace your best guess, put it together, try it, then repeat. With a "real" server the quality is generally _much_ higher, so you don't get most of these flaky problems in the first place, plus the rack mount cases are designed to keep repair times minimal. You can pop open a DL380 and replace a fan without even shutting the machine down. The power supply can be swapped out without even opening the case (and has a nifty LED on it to indicate if it's got a problem), and If you spring $200 for a redundant power supply you don't even need to shut down first. Ditto for the hard drives.
What it really comes down to are 3 things:
1: Is the service provided worth anything? If not, then why bother doing a server at all? If it is important, how many days a month can the system be unavailable?
2: If the system is worth something, and downtime is not acceptable, can it be clustered (e.g.: DNS server) or is it best done as one machine (e.g.: SQL server)?
3: If it can be clustered (and will be -- many things _can_ be clustered but only at enormous expense), then using crap hardware may be acceptable as long as you have 2 or more running, the failure of 1 is tolerable. If it can't be clustered, then you really need to think about "real" server hardware, penny-wise/pound foolish, and all of that stuff.
Is this something of your own initiative or are you being pressured to do this? If the pressure is on, then you are being set up for failure. If you're forced into it get your resume polished and/or try to set someone else up to take the fall (which is unlikely to work since we're talking about $2-4,000 -- chump change for all but an extremely small business where no one else is around to be blamed).
Explain that a compiler tokenizes input from a high level programming language and produces a parse tree which eventually results in object code, which is then linked to static or dynamic libraries with a linker and loaded into RAM by a loader.
:)
I would then immediately jump into the finer points of data structures and algorithms, for example balanced trees, big O notation, efficiencies of various sort algorithms, red/black trees, etc.
Don't forget to use lots of greek characters. In fact this might be a good time to clear up some abstract programming topics, such as lambda functions, macros (in the lisp sense), continuations, anonymous functions, etc.
Suggest Intercal as a good beginners language.
Whatever demo machine you use, make sure to put a block of dry ice in it and claim it is cooled by liquid nitrogen.
I hope these suggestions have been helpful.
There's a thread just recently on undeadly.org that offers suggestions on low-power (under 30 watt) boxes to run OpenBSD.
Chances are if they run OpenBSD they will run Linux as well (although why you'd prefer the linux firewall features over the OpenBSD pf firewall escapes me).
If your main goal is lower electrical cost, that might be a good option anyway. If you are willing and technically competent enough to maintain your own box, you should. Othwerise you give up a _lot_ of flexibility (ability to run snort, dsniff, caching proxy, dns, honeypot, etc.).
Sans offers some great security training, which while not a general "Intro to Linux" does provide some very intensive insight into securing Unix/Linux.
Books can be good, but research them carefuly before you plop down $50 for "linux unleashed" or some other crap book.
Some good books to look at:
UNIX System Administration Handbook (3rd Edition)
by Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein [THE classic Unix admin book, this edition also has some Linux-specific stuff]
Linux Administration Handbook
by Evi Nemeth, Garth Snyder, Trent Hein, Trent R. Hein [Similar to the above, but all Linux specific. Get both if you can.]
Many (not all) OReilly books (especially older ones) tend to be excellent references, e.g. DNS and BIND, Learning the vi editor, Sendmail, Practical UNIX and Internet security, Programming Perl, etc.
One problem you may face is that "Linux" in the "I just installed Suse" sense, is much more than Windows. Where in Windows you'd need to cover basic setup, network config, active directory, basic security, and maybe web server config, in Linux you have all of that plus the functional equivalent of SQL server, Visual Studio, dozens of programming languages, Office, etc.
Good luck! It's a fun ride once you get the hang of it.