Slashdot Mirror
How Hard is it to Manage Different Unices?
vrmlguy asks: "Where I work has several Unix-based servers, all running the same vendor's OS. We are getting ready to buy another big server, and management wants to get bids from other vendors. However, our staff is only familar with our current vendor's OS. Yes, I know that any two flavors of Unix are more alike than not, and yes, I know about the Rosetta Stone for Unix that makes it easy to transfer skills. I want to know about the down-side: What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?"
You have a team of mechanics, and for the last 20 years all they have serviced, as well as driven themselves are Ford automobiles. Now, your boss tells them to jump right in and service Chevrolet autos too. How easy will this change be? Depends on the mechanics and how they've been trained I suppose.
Provided you go with all Open Source systems, I don't imagine you'd be too stretched to maintain it. They'll all talk to one another just fine across a network-- all you'd probably have to worry about would be patching different packages in different ways.
It's when you get into closed source proprietary crap that speaks some protocol no one else has ever heard of that you run into trouble.
It has always been my opinion that if you have people who understand the concepts and underpinnings of how *nix systems work, the flavor of the OS doesn't matter. People who have a good understanding from an abstract point of view will easily pick the differences in syntax, location, etc.
"I'm just here to regulate funkiness."
If you rely on Ford or Chevrolet, you are going to need a team of mechanics. Better to pick a resource that you can rely on and not complicate your life needlessly.
Takahashi Rumiko made beats! DON, taku, DON, taku. . .
I have been doing SysAdmin for a mere 3.5 years. At work we have a few that I need to deal with every so often: HP-UX, Solaris, AIX, SuSE, and Redhat. Seems like all the Techie SysAdmins (myself included) have taken to using the OS they know for a project and then expecting other folks to pick it up ("Oh, it is close enough..."). I wish our company has the insight to pick a standard - 1 or 2! I would LOVE for the versions to follow the same file placement conventions, command conventions, and system management tools. Maybe, someday....
"If you are on fire you can just stop, drop, and roll. If you fall into Lava you are just dead." - my 5yr old daughter
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
$32,593.12
Now can we stop with these stupid, inane questions? I would rather read Jon Katz than these awful Ask Slashdot questions of the past 3 months or so.
I would hazard that a lot of this depends on the number of users, the type of hardware, and the specific Unix flavor you're using.
I've had good luck with a 50/30/20 mix of FreeBSD, Mandrake Linux, and Windows XP (technically it is POSIX-compliant, so I consider it Unix). The large number of *BSD boxen keeps the IP network running smoothly, and you keep the XP stations down to a minimum, in case of virus attacks (hey, they happen). The Linux machines are your main application units, where the magic happens. These days gigabit networking relieves you of any network issues, and you can focus on security policies, which are the real hot point in today's workplace.
I've never had trouble with this recipe. Best of luck!
Karma: Good (despite my invention of the Karma: sig)
Your biggest expense is going to be training, but your company will probably choose to take it out of your clients' and employees' pockets by doing it "on-the-job". Next up would be licensing fees.
Unless Vendor B is offering a competitive upgrade from Vendor A's software, it would be much cheaper to negotiate an additional Server and Client license pack from your existing vendor than to enter into a new business relationship with some new vendor. Unless, of course, the new "vendor" is (sigh) Linux.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
$19.99
For the users, all of the familiar commands shoud work fine. But maintaining the boxen will have a cost. For instance, I know how to create a disk partition under both Linux and AIX and can say that the process is totally different. Also, you'll have to keep two different platforms up to date with the latest patches. And don't forget your apps, which probably won't have binary compatibility. You'll have to make sure that all of the apps that you wish to run are ported to your new Unix flavor of choice.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
If you rely on Ford or Chevrolet (let alone both), you are going to need a team of mechanics. In addition to not complicating your life with redundancy, pick something reliable in the first place for cripe's sake.
Takahashi Rumiko made beats! DON, taku, DON, taku. . .
Not a flippant post.
The quality of Unix sysadmins has declined so much over the past decade that what passes for a sysadmin right now is what I used to call "an operator".
We have 5 unix sysadmins (major transportation company). Not one of them could write a shell script if their life depended on it.
They insist on doing everything by hand and then complain there are no automated tools to them. Their definition of an automated tool really means "graphical front end to those grubby text commands".
They have no appreciation for the modularity of unix, and they look longingly at Windows servers.
Meanwhile, they're all getting paid twice what they're worth because apparently as dumb as the Unix sysadmins are, the NT ones are apparently on a different evolutionary scale where "rock" is considered the most intelligent life form.
So my point is that getting these sysadmins to switch won't happen. They'll piss, bitch and moan about the opportunity to learn something to enhance their skills, then complain the application is screwing up "their" servers.
If only ASPs would take off, my life would be much better, because sysadmin skills suck so bad, black holes pale in comparision to the event horizon of these so-called admins.
So, is it just me or does it bother you that the "Rosetta Stone" states "This custom drawing feature requires IE 5"?
ALL HAIL BRAK!!!
The same principle applies to natural and computer languages - the more you know, the better you understand the fundamentals.
:)
Sure, you might know how to do x,y,and z on your Solaris box, but once you understand how to do it also on RedHat and AIX, you'll understand much better how it works conceptually. Then when you get an HP box, it'll be pretty easy.
Of course, don't run killall on HP.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
At my company we run 37 different versions of Unix without a problem. The guys who says it like fixing a Chevy vs. a Ford doesn't know what he is talking about...
It is fairly easy to transfer sills from one version of UNIX to another.
Plus, it is greate for the resume. When you get tired of this job, get fired, laid off, or transfered you will find it much easier to find another job.
Some of the differences between different versions of UNIX include:
BSD or AT&T based
Disk tools
Adminstrative interfaces and GUIs (SAM, SMIT, etc)
Startup / Shutdown scripts (rc.d vs init.d)
User management
Included tools ("top" is a big one)
Backup and recovery (hp includes fbackup / frestore)
X-Windows (CDE, VUE, etc.)
Some if the similarities include:
user land tools (ps, ls, find, etc)
Directory structures are slowing becoming the same
Generally, this is not difficult to do, as long as your admins understand the bases of UNIX. (Vendor-centric admins sometimes don't, as they get dependent on their vendor's tools.)
The problems can arise with:
1. vendor-centric admins who aren't willing to learn
2. different service contracts creating differing expectations of uptime between systems
3. added costs from maintaining multiple service contracts and training on multiple platforms
4. finger-pointing, if the systems interact
5. rewriting in-house tools which are needed on the new platform, but were not written generically before
6. 3rd party licensing costs may differ (if you are licensing the same product on both OSs)
7. dilution of expertise, since your admins will have to be more generalists (this is often overbalanced by the expansion of perspective in problem-solving that comes from broader experience)
Other than that, I can't think of anything off the top of my head which would make this hard. Generally, it is not a problem to do.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
Make generic scripts that based on the platfrom do their own stuff..
I'm sure there's only a fixed number of things you (and your fellow admins) perform!!
on how you are using each platform. The biggest problems I have seen deal with propietary features in the different Unices. For instance, I worked as a Solaris Admin using NIS+ and while it supported authenicating other Unices that could just use NIS, it don't work well. But that was a years ago.
.cshrc) that set your preferences on the different boxes using uname.
Things that help include creating branchs in your login scripts (.profile or
There is a good O'Rielly book called "Unix for Oracle DBAs" that is a really good cross Unix reference that you should consider picking up.
There are a lot of variables you haven't talked about, e.g.:
1) What sort of applications do you have running on these servers and how interoperable are they? Does it matter how interoperable they are?
2) And further, are those apps dependent on that vendor's Unix?
3) How much resistance is there from the staff to learn something new?
Assuming the above aren't a problem, then it shouldn't really matter. Go open-source and save a buck or two.
I watched C-beams glitter in the dark near the Tannhauser gate.
If you are migrating from an Open Source Unix, Linux, BSD, etc to a closed system such as AIX or Solaris, I'd strongly recommend getting a good support package. Closed systems generally have little good online material, and people from Open Source systems usually go straight to Google.com when they have a problem. In a closed system this doesn't work very well.
Gamblers Forum
my company runs almost 10 different flavors of UNIX for production purposes. since i'm the only UNIX admin here, keeping the machines update is quite a task. most of the machines are on a private net, so i don't have to worry about patches that often, but when it comes time to fix a bad harddrive or broken ethernet card, i wish that i could just repeat what i did on the last machine.
also they might seem the same, every UNIX flavor has it's differences. any time something goes wrong, you have to deal with 10 different salesmen from 10 differnt vendors.
good luck.
I'm going to try and not sound like a troll here. But this Ask Slashdot question seems complete rubbish.
Coukd the Slashdot folks be a little more discriminating in their choice of questions, please? The most entertaining/thought-provoking parts of this story, seem to be the idiot troll posts. This is hardly a thought-provoking or difficult question to answer/figure out with the most miniscule of job skill.
To answer this silly question:
The difference is: a lot, due to training/familiarization, support contracts, possible hardware differences, etc. DUH.
You can mod me down if you want.
And you can tell me that the real Unix Power is in the Command Line and in VI (or Emacs).
But today, if you give good training to your staff and give them good management tool, like the Tivoli suite from IBM and the Unicenter from CA, and I know you can name it a dozen of this Multi-Unix management center.
With this kind of tool, you can realy incress the number of Unix Boxes managed by one Unix Admin!
-- Do you really want to fly in a plane designed by one who never pilot ?
Ceci n'est pas une Signature !
It works like this . . .
You learn one flavor of UNIX, get to know it inside & out. And because of the shop, the job market, whatever, you start working with another flavor. And it will look weird because it's different.
Sometimes the differences are due to developers' choices, sometimes they fix problems existent in the first flavor you've encountered, sometimes they cause problems you didn't have in the first flavor. And sometimes what's weird about this new flavor is because the guy who set the computer up botched things.
Also, the longer you know one flavor of UNIX, the more likely you are to call any new flavor you encounter ``braindead".
Except when it comes to SCO. Trust me on that one.
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
How much of a raise are you asking for?
-... ---
Sure, an environment with only one vendor's OS deployed is easier for the admins to handle. However, if a problem develops, that problem will affect EVERY SINGLE MACHINE you have. Don't lose sight of that in your zeal to minimize the admins' workloads.
Learn to spell: nickel, missile, lose, solely, amendment, speech, kernel, probably, ridiculous, deity, hierarchy, versus
Here at NDSU I heard a story about a habitual public lab pr0n offender. Seems that this character was known to the tech staff here: always coming in very early or very late, sitting in the corner, turning his screen so no one else could see...obviously a pr0n seeker. But nobody could quite prove it and remove him (a NEThics office would be quite useful here, as long as it didn't have that stupid name).
Until one day he slipped up. In the smaller side labs there's really no "corner" computers that nobody can see. So that would mean using the instructor's computer at the front of the room, which face the opposite direction. Unfortunately for Mr. Pr0n, a teacher had left the overhead projector on and attached to the computer. More unfortunately, Mr. Pr0n didn't notice...his attention was elsewhere. Eventually somebody in the lab stopped giggling and retrieved a cluster worker. The worker confronted Mr. Pr0n, who stoutly denied the accusation until the overhead screen was pointed out to him.
What would a sane pr0n addict do in this situation? Fess up? Stick to their lies? Well, this guy got reeealll red in the face, and then BOLTED out of the lab.
He's not welcome here any more
Also, running your software on these different flavors of UNIX will shake out some bugs that you might not find on just one or two platforms.
One major consideration will be the service contract with the vendors. With 2 vendors, you'll buy 2 service contracts. You can have all the best sys admins you want, but I'm sure you'll need at least a minimal service contract for a commercial Unix. Can adding a second contract add a lot to overall cost? Hard to say without any details of the company, but I'd guess adding a basic service contract from the new vendor will significantly add to TCO.
Developers: We can use your help.
Not a flippant post.
The quality of Unix sysadmins has declined so much over the past decade that what passes for a sysadmin right now is what I used to call "an operator".
We have 5 unix sysadmins (major transportation company). Not one of them could write a shell script if their life depended on it.
They insist on doing everything by hand and then complain there are no automated tools to them. Their definition of an automated tool really means "graphical front end to those grubby text commands".
They have no appreciation for the modularity of unix, and they look longingly at Windows servers.
Meanwhile, they're all getting paid twice what they're worth because apparently as dumb as the Unix sysadmins are, the NT ones are apparently on a different evolutionary scale where "rock" is considered the most intelligent life form.
So my point is that getting these sysadmins to switch won't happen. They'll piss, bitch and moan about the opportunity to learn something to enhance their skills, then complain the application is screwing up "their" servers.
If only ASPs would take off, my life would be much better, because sysadmin skills suck so bad, black holes pale in comparision to the event horizon of these so-called admins.
Are what's going to kill you. Having to support software and software interoperability between different platforms can be a serious pain. A mono-culture is easier when dealing with software. However if you are presented with a significant enough savings from another platform, consider it.
Your admins, if they're any good, should be able to adapt to a different UNIX easily. Yes there are differences, but not ones that should trouble an experienced admin any longer then it takes him to read a couple man pages.
it all depends on the reasoning behind your move.
i've worked in several environments where there are two different Unix flavors, typically one open source (Linux, FreeBSD) for the web servers, and one commercial (Solaris, AIX) for the backend DB servers. these arrangements work very well.
running two OS's is not hard as long as there is a good reason to.
If you are happy with the vendor you are with, and everyone likes working on their product, it makes NO sense to switch vendors to save a couple bucks. The technicians will spend (as read by management: waste) their time learning the ins and outs, do's and dont's of the new OS. Not to mention possible incompatibilities, and more wasted time futzing with network integration, plus warranty and support calls (Sun: Its your IBM box at fault! IBM: its your Sun box at fault!) If you are happy with the platform you are on, stay with it!
Explain that to management, and I'd be very suprised if they didnt continue with the origional vendor.
Statement of Bias: I "administer" several UNIX OS versions (Solaris, IRIX, Linux, occasional HP-UX), but in an isolated network with no outside connections (so very little emphasis on security).
Two factors come to mind:
No matter how close the systems are, you will still "loose" time to training (either formal or OJT) requirements for the new system. This may actually be a benefit for your staff (wider perspective, more to put on Resume).
Depending on how much focus is placed on security, you may end up doubling the time required to track vulnerabilities and install patches. Again, this may be an advantage as well since a single-os shop tends to have equal vulnerabilities on all systems. In a multi-os shop an attacker will have to work harder to get control of everything.
It is easist to manage servers from only one vender. Unix makes ti easy to transfer skills, but here is the contradiction: It is easier to manage servers from many different venders and versions, than to manage just one server that is different from the rest.
When you have all OSes the same it is easy because everything automaticly transfers. When all are different it is harder because you always have to remember the correct incarnation of each procedure, but because they are all different you get in the habbit of looking it up each time. When all are the same except for one machine you forget on that one machine that everything is different and you aply the wrong incarnation (ofte with disasterious results, see discussions of killall linux vs hpux on comp.risks) Because of this, the one different machine will get [invalid] complaints often due to these differences.
If you can't stick with one vender, then you should go with many so you are in the habbit of checking the differences. At the very least get some linux (debian, redhat, suse), and bsd (free, open, net) machines in house now, and use them for production. You need to make sure that your admins are used to subtile differences. The other alternative is to just stick with one vender, but not only do you pay more, but your admins become lower quality as they learn only one system. (think of it is a resume builder, you want different systems on your resume!)
It seems to me that the biggest cost is in sysadmin time. I figure it this way, at work I use a few UNIX systems. We have one machine running IRIX, a couple running BSD and one running Linux. Now, when I write a script one one of the BSD machines, it works on all of them, but it may or may not work on the Linux machine, and certainly won't work on the System V-esque IRIX machine.
Now, if your sysadmins employ a lot of scripts, figure you'll have to spend twice the time maintaining them if you have two different platforms that are not fully compatible. You can minimize this if you stick to POSIXly correct scripting, but you'll never completely eliminate it.
The same goes for custom programming. For instance, if you're running everything on BSD, and you want to take on a Sun machine running solaris, there may be some issues with the occasional socket call that Sun implments differently from the rest of the world.
So, the more custom scripting/custom apps you have, the more time your sysadmins will have to spend maintaining/porting/testing the stuff.
---
Play Six Pack Man. I
Having more than one unices requires the sysadmin to keep dependencies and software packages up-to-date on different platforms. This can get quite difficult if one has to actually find the right package to install for a particular OS.
The Gentoo Linux OS would make some maintence things easier, and dependency/package management may be easier... how much easier, I don't know.
This is the last post.
Sorry, were done.
I don't really know my self as Ive only tried one flavour of unix (Linux). But different distros are similar though and I can easily manage Different flavours.
Try and stay with similar families of unix such as BSD based unices or Linux so they will have similar ways of working together.
Over I think it would be easier to switch to a single flavour such as Linux to make things easier than trying to manage different systems.
$ yes >
From personal experience, I found that backup and recovery can be quite different depending on the flavours involved. For example, I back up my AIX systems with /usr/bin/mksysb, ftp the file to a system that is connected to a tape library and copy the image to a 4mm tape. I can do a bare-metal recovery from that tape to any equivalent or better RS/6000 in about an hour or so and have an exact clone of the original system as of the date the backup was taken. In this regard, AIX rocks.
/usr/sbin/ufsdump, but restoring a system from tape is more involved, and I cannot restore that tape on a different class of Sun hardware.
My Solaris backup and recovery strategy is not as elegant in that I make backup tapes via
I do not expect both to work identically, but there are some significant differences between the two.
*** Where are we going? And what's with this handbasket?
The short term costs to retrain staff for the new system will be higher but the long term benefits will definitely outweigh them. Once you build a multi-OS capable IT department the cost to add new hardware later on becomes significantly less. By not being locked into one OS (and one vendor) you have the freedom and flexibility to choose the best solutions for future problems (as well as hunt for the lowest cost). The smart thing to do is diversify your IT shop as much as possible so that you can insure you always have the right tool for the right job. No single vendor or OS can provide all the answers, regardless of what IBM/Sun/Microsoft may try to tell you.
Had almost forgotten what she looked like for a second *smiles dreamily*
Even if you occasionally have to take a moment to look up a command name or check the manpage for the proper syntax, this isn't going to slow you down all that much in the long run. The fundamental concepts tend to remain the same. (Actually, I've occasionally seen more headaches arise from upgrading the OS than from changing to a different UNIX vendor!)
The only major issue to deal with is when you're writing an application to be run on multiple OS. In this case, you may be in a world of frustration. But as long as each server is doing its own thing, and you're simply installing applications that are made to compile on the systems you're using, there's not much for you to worry about.
Sounds like his boss said Dude, you're getting a Dell
One of the biggest problems can be lack of compliance to actual or de facto API standards. An OS that doesn't track community standards closely, like my pet peeve, HP-UX, can make a lot of work. Many times, we have been wanting to go forward with a new architecture for some aspect of our systems, only to be held up for quite some time because the software would not compile for HP-UX. The number of open source projects we've needed to port to make them work as well on HP as on Solaris or Linux is considerable. So, keep in mind that sometimes a non-feature like the system library environment can make a lot of difference in running an OS.
I said last post! Stop posting.
This is the LAST ONE!
You may wish to scour Apple's websites for a (partial) answer to your question. Apple has been advocating non-monoculture systems for years out of neccessity. They have had some research done for their marketing in this area. I would assume that some of what they've done (especially now that they are actually selling a variant of unix) would apply.
Just keep text-file logbooks as you learn new things about the different UNIX implementation. Keep them in a hierarchical database on an NFS file system or web server somewhere, name the directories and files consistently by OS and topic (topics such as DNS, network booting, firmware, SCSI naming conventions, package management, etc.).
I do this at home to juggle Solaris, OpenBSD, and Linux and it works well. If I forget how to setup DNS under Solaris, I just go to <base_dir>/Solaris/8/DNS_Setup.txt, for example.
Also, install all of the on-line documentation you can and have it network-accessible. For example, when the man pages aren't detailed enough, on-line Solaris Answerbooks can save the day.
Also, keep well-organized bookmark lists for useful websites, such as http://docs.sun.com or http://sunsolve.sun.com, that cover your particular UNIX.
Having any number of UNIX implementations really isn't unmanagable (unless they have broken network protocol implementations). The key to success is documentation and more documentation (and unambiguously sharp sysadmins). On that note, if you don't have faith in your system and network administrators, you should just give up and stick with one OS, since no amount of documentation helps a truly stupid human.
Healthcare article at Kuro5hin
Update the frickin' lameness filter to filter out those page-widening posts! Jeezus H. Christ, I could whip out the Perl required to filter that stuff out in an afternoon.... this is getting old.
Mod down people who tell people how to mod in their sigs
If you want to keep a consistant os across different platforms, Linux is the way to go. It will also save you a ton in License fees.
Money.
You obviously already know that managing support contracts from multiple vendors is going to suck. I would also recommend taking a long hard look at ongoing support charges.
For example, we have both HP/UX and Sun platforms where I work. We have both servers and workstations. For the workstation support contracts on similarly sized machines, there was a world of difference in cost.
The annual fee for an HP C240 workstation was somewhere between $2500 and $3000. The same annual charge for a Sun Ultra of equal speed, was between $1000 and $1500. Multiply that by the number of workstaions you have to maintain, and it can add up very quickly.
The up front cost typically isn't where they get you. It's on the back end. I would research the back end on all of the platforms you are considering very carefully before making any final decisions.
Hope that helps a little.
NO MORE!
Stop posting. This is the end!
I really mean it!
But today, if you give good training to your staff and give them good management tool, like the Tivoli suite from IBM
I have a medium-sized Tivoli installation, and it has not really reduced the number of SysAdmins we have. Tivoli still has some bugs in it, and some of the modules (i.e. software distribution) do not work consistently. Furthermore, Tivoli has problem running large scripts on remote servers.
In fairness, it does a very good job of monitoring systems, and it takes care of the more mind-numbingly dull and repetitive tasks for us, but we still need to have skilled UNIX admins around.
*** Where are we going? And what's with this handbasket?
For example, on Solaris (without Veritas Volume Manager), you have to "carve out" your disk filesystem by filesystem, and work with devices in /dev/dsk/cAtBdCsD format. On AIX, the concept is totally different with Logical Volume Manager, wherein filesystems can be created on the fly. But HP-UX uses both in an odd fashion, forsaking slices and using a "castrated" form of LVM. This is just one example, as you will find other things in HP-UX such as the useradd command being identical to Linux and Solaris, and the SAM tool being very close to AIX's SMIT utility.
In the end, as you will find, there is no uber-Unix that will carry over to all of the other flavors. IMHO, HP-UX is as close as you will get. But, my personal preference of all Unices is AIX due to its ease of use (an IBM tool easy to use? I know it sounds like an oxymoron) and robust capabilities, combined with Linux integration in the most recent versions. Flame as you will, I'm interested in hearing anybody else's insight.
--Chag
Apparently the Rosetta Stone can survive 4,000 years of Mother Nature's worst, but cripples in minutes under the power of the Slashdot effect.
Most companies I have worked at or know people at go with a third party backup solution such as the ones from Tivoli or Veritas.
Makes your backup/recovery fairly consistent across different products, plus everything can then be managed from a central console.
W00 H00! I am 133t. I g0t l4st p0st!
Bow down to my supremacy!
0wn j00z!
I've found that operationally, my ability to move between Tru64, Soalris, AIX, HP-UX is relatively seamless. My biggest hurdles have come when doing hardware troubleshooting, upgrades and maintenance. Each vendor has their own unique approach to device names, hardware settings and architectures, which I've found to be the most difficult to master when moving between unixes.
I GOT THE VERY LAST POST!
I am so l33t you can k1ss my sh1ny b0tt0m!
Guess folks at SGI never heard of the "path of least astonishment", such as printing a usage message if there's no arguments. Then again you could argue that it's not very astonishing if typing 'killall' really does kill *all*.
Three dits, four dits, two dits, dah!
Radio, radio, rah rah rah!
Unfortunatly that's not so.
/. you would want to see that there are plenty of apps and opensource support for the new platform.
EG. If you are running Solaris boxes currently and want to look into running DECs, people will be all confused for at least 6 months or more. If you running Solaris and want to try RedHat or some other varrient of linux, that's not to hard to pickup on. You really have to look tward the furure, and not the present, If the OS looks like is been progessing and and been relatively bug free and is secure, then the training may be a huge bennifit. But if you want to move to a cheaper platform that is less relabile/secure why bother. Also I assume if your looking for feedback on
It's nice to have the abbility to just do a quick search on google and get an answer and maybe even a fix to a problem in less then 15 minutes, rather then a closed source... sit on hold for 30 minutes, send a stupid dump file to the vendor, wait another couple of hours, and your problem was some stupid little switch that was undocumented, and they refuse to "support". I personaly know that I have wasted days with stuff like that.
You just HAD to link to the Rosetta Stone for Unix, didn't you? And from SLASHDOT'S FRONT PAGE of all places. What, you didn't think it would be slashdotted?
You bastards. You stupid, stupid bastards.
This is the v3ry l4st p0st!
I b34t j00z! 4ll!
LASTY last last last!
can't you guys see his is a 7r0lla>0r ?
since the stone has been /.ed i found other links to it
http://www.darklab.net/resources/unix-rosetta.pdf
http://www-ccar.colorado.edu/~jasp2/Graph.html
"What kind of unixes do you run?"
"Oh, we have both kinds. RedHat and Debian.
When I worked for a Tier I isp as a 3rd shift unix admin, it was just a fact of life. You tend to learn other os's quickly due to the urgency.
If it isn't a mission critical shop, then train them and things should go fine, if it is a mission critical shop (~15 min resolution time where I was working) switching to multiple os's requires one ping-pong table per platform, 1 pool table for every 3 architecures. That seemed to keep the crowds happy where I worked.
--
WickedLogic
Any new item will add some additional overhead. In general most of the knowledge can be used across multiple areas. Its is sometimes the small things that trip you.
Were I worked they had a HP system running HP's flavor of Unix. In checking out new software we would use a second HP system that was the same model but a smaller variation of it but ran the same OS. What would trip us up sometimes is they used different tuning parameters. Tune a app up on one system and it would go bonkers when you put it into the other.
Now put that in the light of different OS that use different parameters to accomplish the same result. If you are thinking of one system and adjust the other, how long will it take when you trying to figure out why it just does not perform?
Handling different systems can be easy or it can be a pain. The people working on them must very diligent in thinking twice before doing something. You might have to form a formal / informal methods of reviewing changes to make sure things are done correctly, even the smallest of changes. This allows a second pair of eyes to check to make sure it correct. Just assuming you are correct will sometimes prove you are wrong in a very nasty ways.
ls - lists a directory
cat/less/more - look at a file
grep - find something in a file
emacs - edit a file
perl/csh/bash/tcsh/sh - write a script
ssh - log on to another machine
gcc/cc/gnat - write a portable program
other gnu tools - blow yourself out
etc etc.
seriously, the differences between unixes isn't very much generally.. usually its administration, and having to think about network byte orders, endians and the like. All POSIX unixes are pretty much the same really. The speed with which studios
ports complex numerical graphical apps between SGI and Linux proved that point I think.
Go for which ever *nix has the best support for your particular domain / specialist hardware requirements / user profile. I woudln't reccommend sticking with a flavour of unix just because thats what your used to, you missing out in price and gains then. If price is an issue, linux freebsd/netbsd/openbsd - is a good bet.
The reason homogenous environments are easier to manage than heterogenous environments is due to complexity.
Simply put, if every server and workstation is identical, interoperability is not an issue, and the work associated with tracking, testing, and applying changes to that one, homogenous OS image is minimal.
The moment you branch out into different configuations of the same OS version, different OS versions, or different OS platforms, you've increased the complexity of the system, and thus increased your workload. Suddenly, interoperability is a factor in every decision, and issues with multiple versions and/or vendors must be tracked.
I've been meaning to write a short paper on this for some time, and attempt to relate it to Christopher Langton's Lamba parameter for the measurement of complexity (in the 3rd Annual Proceedings of the Artificial Life Conference). I've studied the identification of single points of failure for some time, as well as the question of "how many sysadmins do I need?". Both answers are directly related to the complexity of the system being managed (here, defining "system" as the collection of applications, OSes, hardware, and networks that comprise the scope of a sysadmin's responsibility). There are indeed identifiable factors that define the heterogeneity of an environment, and the ways in which these dimensions impact such things as the number of SA's required to manage them can be defined.
.@.
on any *NIX I've ever seen - that's all you really need to know in order to be a good BOFH.
};>
Avoid a monoculture, diversity helps robustness.
I have written programs on various Unix flavours for more than 20 years. Bugs, hidden on one system, are obvious on another - that is good, find bugs early. Yes: porting costs up front, but you get long term rewards.
If you only buy from one vendor, what incentive do they have to remain competitive.
If you run a mixture they will all try to increase their share and work hard to keep you happy and guard the share that they do have.
I'm still working, admin of 7 different flavors of *nix, and can even spend a bit of time reading /. of course I consider myself to be one of the best that's ever been, one of the best that is here right now, and probably one of the best that ever will be.
/. right now ;-) ... of course I've got about thirteen different projects running simultaneously right now and while waiting for some jobs to finish running, I think I do indeed deserve a /.-reading break at least a couple times a day.
Posting A/C cuz I work fer a gubmint organization, and yes your tax dollars are paying me to read
..but I am pretty familiar with quite a few different flavours of UNIX & Linux.. I use Sun Solaris 8 daily, I used to own and run an SGI Irix 6.5 box daily as well.. and I use Linux alll the time.
:)
I found that knowing one UNIX was enough to get you around the various other flavours with relative ease.. but that really goes out of the window when it comes to performing advanced admin on a system when you are used to another.. it is quite surprising how they vary from vendor to vendor - it would make life a LOT easier for you and your team if you try and stick with a single vendor.. IMHO at least
"Hey! Unless this is a nude love-in, get the hell off my property!!"
Here is a Google cache of the link he mentioned
But not as hard as you'd imagine. I use AIX, Solaris, and HP-UX on a weekly basis, as well as MacOS, MacOSX, and w2k (workstation and server).
/opt/apps/local
The biggest problem with a mixed environment is keeping it up to date with patches etc. Keeping track of that stuff is a complete PITA; I can't imagine how much more difficult it is in Linux, where the patches aren't on the vendor site (are they?).
Besides that, the big thing that you'll need to do is make sure everything is sort of in the same directory structure. For apps that you install, put them in the -exact- same directory. For example, all my unix boxes have the same layout:
/opt/apps
/opt/servers
/opt/data
/opt/src
/ usr/local ->
That way, it doesn't matter as much which box I'm on, and I don't have to remember exceptional cases. It also makes maintenance easier, because all the exciting stuff (non base operating system) is in a known structure. That means you can write scripts, etc to monitor everything and you don't have to change them on a per-host basis. It also means you can just copy the config.status from box to box (or directory to directory) and build without reconfiguring everything.
'Luck!
http://www-ccar.colorado.edu/~jasp2/Graph.html http://cam.radioactivecat.com/unix-rosetta.pdf Not as graphically friendly as the orginal... But, Still gets the point across...
1) You can install the same shell on just about all UNIX's. Most people where I am prefer tcsh as it has some nice features.
2) You can standardize on scripts, either use csh (blah) or sh. We prefer sh as it is found on just about EVERY unix (Sun, HP, AIX, BSD's, Linux).
3) Avoid vender extensions to the basic shell. HP has done some aweful things there in its bourne shell and they are not compatible with Sun and in some cases Linux either. I.E. Always use `cat foo` and not $(cat foo) in sh scripts. There are other things like that.
There are problems in supporting more than one UNIX, but there are also workarounds if you do it right.
Only 'flamers' flame!
If you have an employee who isn't willing to learn, get a different employee.
2. different service contracts creating differing expectations of uptime between systems
Can't argue with that.
3. added costs from maintaining multiple service contracts and training on multiple platforms
Ditto
4. finger-pointing, if the systems interact
If people are properly cross-trained, this can be minimized, but will still occasionally happen.
5. rewriting in-house tools which are needed on the new platform, but were not written generically before
Good coders make their code portable in the first place. If your coders don't, get different coders.
6. 3rd party licensing costs may differ (if you are licensing the same product on both OSs)
Can't argue with this, either.
7. dilution of expertise, since your admins will have to be more generalists (this is often overbalanced by the expansion of perspective in problem-solving that comes from broader experience)
The expertise should be at a conceptual level, not at a specific OS level anyway. I think most of us will agree, for example, that it is much more important for an admin to know how dhcp works than to know how to start the service on a specific OS, which can easily be found out.
"I'm just here to regulate funkiness."
I have suppoerted several different flavors of unix from BSD to SysV. I try to focus on standards. Like all BSD systems did something this way and most SysV implementations did something another way. I believe that there is a SysV and BSD spec that defines what should go where. Also, on top of that we have posix levels and Unix95 etc... that most OS's are as compliant as they've chosen to be. (even NT) The primary differences (at least from a command point of view) is the volume management tasks. The bad news is that whenever a real high profile project somes up, they don't usually pick me since there are more specialized people with more uninterupted experience with that flavor. I've worked at 3 companies now that have tried to combine Sun and HP Unix support teams and all 3 failed miserably. Mostly due to admins reluctance or inablility to do and learn more. Also for the reason above. If I'm an HP admin and start dabbling in Sun, then management is going to pick the guy that kept his focus on HP for the big projects and pick the pure Sun guy for the big Sun projects! Arrggh! So management comes up with the idea and then punishes you for following it. Bottom line: I love the challange and variety of supporting multiple platforms and would pick that if given a choice. But it doesn't seem to be a career booster since most managers are REALLY only looking for 1 specialty no matter what they say.
I think that's what he was saying:
"Also, the longer you know one flavor of UNIX, the more likely you are to call any new flavor you encounter 'braindead'.
Except when it comes to SCO."
Should be followed by: "You'll call SCO 'braindead' no matter what."
Exceeding the recommended torque is not recommended.
I don't know why, but when I read your post, I immediately thought of this thing.
Although it looks like a complete joke, there is a lot of truth in there.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
I write shell scripts to automate tasks, but am forced to support both HPUX and Solaris. Now Tru64 has been thrown in too. I've found that even the most basic tools, e.g. lp vary significantly enough between platforms that it makes my life hell. Writing cross platform shell scripts is a pain because shell scripts ultimately rely on the underlying basic utilities... and when they differ, they force you to either add a lot of workarounds or maintain multiple versions of a script.
avoid HPUX like the plague!!!! shared memory limitations, terrible default terminal settings, unless XPG4 is turned on all the tools function in an atypical fashion, etc... I've yet to find anything to like about HPUX.
Hello,
I've been sysadmin at various points for
a small cluster which has had up to 6
different UNIXes:
Digital UNIX
HP-UX
Linux
SunOS 4.1.x
Ultrix
Irix
Now, I was able to manage each of these pretty
OK, Unixes *are* alike. However, getting patches
and whatnot differs over each arch.
So crudely, I would say:
SysadminWork =
A * number of UNIXES
+ sum_i(Bi * number of machines_i)
where A is a very big constant,
i is the index of each UNIX,
Bi is a small constant, the marginal extra
effort to maintain one more machine of type i
What I mean is this:
for each UNIX, you have to do a fairly large
amount of research + effort to learn/aquire
materials and knowledge for things like upgrades.
Having done that, it's easy for you to maintain
another UNIX box of that type: the cost of each
extra machine is low, and you can do things
efficiently via scripts.
So the least wasteful way to use your sysadmin
is to have one arch/OS.
In my case, my life became progressively easier
as I got rid of UNIXes and concentrated on running
Linux only.
I've rarely seen mono-unix environments. What is more common these days seems to be a combination of an open-source unix and a commercial unix.
open source operating systems such as Linux or FreeBSD for handeling things such as web serving, MRTG, to take advantage of cheap hardware, and a commerical OS such as Solaris or AIX to handle the tasks that can't be handled by an open source solutions, such as Oracle or something hardcore that requires a big and bad machine.
In these cases, it's quite easy to run two unixes. It really depends on what you need it for.
At the big-3 auto companies, you might have 15,000 to 20,000 UNIX systems (spread over 30 or 40 countries and hundreds of buildings).
Running on those systems are at least hundreds of engineering applications (some in-house).
You need to provide your engineers a common environment regardless of location or UNIX version.
The industry trend is to reduce the number of vendors to save money. And that works *great* as long as you retain enough vendors to play them off one another for lower prices.
The opinions from the "seasoned" sysadmins with a couple of SGI's, a couple of Sun's an AIX box are laughable at best..
I mean, waht do you do? Do you just serve up content on software someone else writes? (Http, or SQL database?)
Or do you write your own real-time communication software? Writing device drivers across platforms can be sticky (if you are writing a high level device driver, utlizing CDLI or DLPI) to down right icky (you go down to the metal).
For us, switching platforms has a higher cost than the money spent on the boxen.
In the future, I would want to not be isolated from my friends in the Space Station.
> You'll call SCO 'braindead' no matter what.
Exactly my point.
What else can you say about a UNIX flavor developed by Microsoft? It takes all of the user unfriendliness of UNIX & combines it with the bad programming habits of MS. And SCO (before they were bought out by Caldera) failed horribly at maintaining the resulting code.
At least Caldera did the sensible thing: let SCO die, & offered all of the customers still using it a way to migrate to a better OS.
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
3) Avoid vender extensions to the basic shell. HP has done some aweful things there in its bourne shell and they are not compatible with Sun and in some cases Linux either. I.E. Always use `cat foo` and not $(cat foo) in sh scripts. There are other things like that.
...
...
... file
/.
...
... /etc/passwd, normal find /tmp -print would output
go here...
And of course, if you've been following along for a week or two, you know that this (BING!) is a Useless Use of Cat!
Rememeber, nearly all cases where you have:
cat file | some_command and its args
you can rewrite it as:
<file some_command and its args
and in some cases, such as this one, you can move the filename to the arglist as in:
some_command and its args
Just another Useless Use of
Dangerous Backticks
A special idiom to pay attention to, because it's basically always wrong, is this:
for f in `cat file`; do
done
Apart from the classical Useless Use of Cat here, the backticks are outright dangerous, unless you know the result of the backticks is going to be less than or equal to how long a command line your shell can accept. (Actually, this is a kernel limitation. The constant ARG_MAX in your limits.h should tell you how much your own system can take. POSIX requires ARG_MAX to be at least 4,096 bytes.)
Incidentally, this is also one of the Very Ancient Recurring Threads in comp.unix.shell so don't make the mistake of posting anything that resembles this.
The right way to do this is
while read f; do
done
/tmp/moo
/etc/passwd
and xargs would see two file names here. Changing the record separator to ASCII 0 means it's now valid for a file name to span multiple lines, so this becomes a non-issue.
Really, the more I use anything else, the more angry I become trying to use Windows. People who don't know there's a better way don't suffer this way. :)
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
As far as problems go, the only real problem you have is getting used to the new environment. My company is running HP-UX 11, AIX and RedHat Linux. HP-UX is a dream to configure and when I have to work on AIX, I have to most of the time, take the back roads through the console. It can be a pain but it's just like any new system. You just have to learn it. Oh, and sometimes root on HP-UX != root on AIX... but we're working on it.
You should write it then add it to sourceforge. Then you could say that you are a contributer to the slash code.
.sigs suck, thus nothing here.
You mean I can't just ship it after it compiles. Well, that changes everything.
Sincerely,
William Gates, III
Installing Tivoli or CA Unicenter is a nightmarish ordeal that is vastly more difficult than doing without it.
The majority of sites supposedly running CA's horrorshow actually have it on the shelf. We've found that it's easier to pretend we installed it than deal with it.
And for the yearly license fees you could hire dozens of experts... Any shop that depends on that sort of thing is doomed.
Note that training cost should be added to the overall cost of the equipment purchase. Tell your managers to send the staff to a training course offered by the vendor if they do buy this new box with a different OS.
Amen to this statement! I've discovered some pretty obscure bugs when switching between OSF 4, OSF 5.1 and Linux. For each change of OS new "undocumented features" were discovered.
(quote from from TG tshirt) Commands and methods are slightly different per differeing Unix vendors. This would not make a difference for good admins. The output of the commands is slightly different enough to have to modify established perl or shell scripts. And after all is said and done, your sysadmins are going end up with their preferences, things they miss on the old Unix, things they like better about the new one. But all in all they will end up with a much broader set of skills to apply. Back to my subject line, unless you are going to be using an open OS such as Linux or BSD, then you are stuck with different hardware as well. Each vendor is tied to their own hardware. If you are running AIX, then you will be getting big black shiny rs6ks. If you go with Solaris, then you get grey & lavender boxes (matte), etc... Which opens up a new can of worms; hw maintenance contracts, window of downtime/availability, quality and price of hardware, etc...
Hard
:wq
The problem is there's no "Computer Guys" out there.
I've done 24 or more Unix varients including
Coherent, Xelos, Concentrix, RTU, *BSD, *Linux*,
SCO, Solaris, SunOS, etc... And VAX/VMS, RT11 etc.
I started as a Field Service hardware guy and worked my way to sysadmin through support jobs
and ended up as a trainer. If you understand how a system works you can pick up the commands needed to solve all the problems.
If you think a computer is a magic self-repairing intelligent being... you'll lose.
I think some of the worst Sysadmins were programmers who failed their way down to sysadmin and some of the best were operators who learned their way up in the old days.
Now the operations staff is so compartmentalized they have specialist sysadmins who just fix print queues and just add users.
If you haven't brought up a server from the raw iron including a full OS install and partitioning you ain't a sysadmin.
Bill Pechter
--bpechter@monmouth.com
Absolutely. That's what reference materials are there for: reference. Now if we could only get those in charge of our education system to learn this simple principle...
Let's say you want to install the GNU version of some standard system utility, because the HP version has not advanced noticeably in 22 years. Not an uncommon scenario - compare HP awk to GNU awk, or note that Perl 4 ships with HP-UX 11.00.
/etc/groups file! Or maybe not.
So, you get the good stuff, compile it (Oh, crap, you didn't buy the AN$I C Compiler for a bajillion dollars? You've got the "brain-dead" K&R compiler? You poor sap. Have fun getting gcc installed, you're going to really, really need it.) and decide where to put it. Your best bet is to follow the HP-UX Porting and Archiving Centre's guidelines (DON'T try to use HP's; they don't even try to conform to their own published standards so it's a lost cause).
Now, you've got the new version ready. You need to disable the old version. Wait, have I mentioned the dreaded HP "Depot system?" It works like this: HP gives you a bunch of patches that you desparately need because of numerous remote rootable kernel bugs. Boo-rah. That'd be great if they weren't six months later than every other unix vendor's patches, never mind that. Anyway, you will have to use the "Depot system" to install them.
The software to manage depots is called SD. But wait! Don't type sd, that is for ubergurus, and consequently if you have problems nobody at HP will be able to help you! Use swlist, swinstall, etc. instead - these are aliases that let the system know you are a (l)user not a god.
So, use swinstall to install your patches. But, you didn't do anything that screwed up the K&R compiler did you? Whew, that's lucky. The kernel rebuild and reboot process is not too forgiving when you are forced to use the depot interface.
Anyway, back to our GNU software. We need to disable HP's compress and link back to gzip instead, for legal reasons. But, that breaks SAM!
Did I mention sam? Oh, sam is wonderful. On my $500,000 N-class machine, if I try to modify one of my three ethernet interfaces using HP's sam utility, it shuts down and deletes two of them. What fun! Guess I better get a depot patch set for that, maybe it'll fix the bug where sam eats your entire password database if there is a blank line in the
SO, anyway, we can't remove compress. Let's install something else. Hey, we did it, it works, and the users have been prevented from using the broken antique HP version by the simple expedient of chmod -x. But I still have to install those kernel patches... hey, the depot system has run rampant through my system and replaced the executable bit I just stripped off!
Luckily the depot packaging system is unbelievably fat and redundant (without the reliability redundancy usually implies, though, so be sure to check those checksums) so you can just plunge into the tar-ry mess and find out in advance how it's going to screw you. That won't prevent it from happening, it'll just let you know how to fix it afterwards.
Or, use Linux or BSD on an Alpha box and get superior performance and reliability for a quarter million dollars less. But that's not the Merkin way!
--sd uberguru
For a decent sysadm, the differences between various unices should be pretty easy to manage, once they get the hang of the new system.
Bug if you are developing your own software using a non-portable language (i.e. C or C++) it could get to be a hassle.
Sysadm training is a one-time thing.
Your software development/test/release cycle is recurring, and having to compile/test/release for multiple targets will complicate things from now on.
It's not even the issue of dealing with OS differences at the programmer level (although that too is not insignificant). It's having to keep multiple test beds in sync, control releases so the right versions go to the right machines, etc.
2 targets might not be too bad, and if your 2nd unix is one of the free ones, it might be worth it for the savings.
The good news is there are a few advantages to be had from going through the porting process.
Certain bugs that don't cause problems on one architecture (and so are not detected) are likely to cause problems on the other. That's a good thing.
Also, regular porting makes sure that you're dealing correctly with architecture-specific issues. If you find you NEED to switch platforms in the future, it'd be much harder if you weren't going through this process all along.
Posted from my Android phone. Oh, I can change this? There, that's better...
Be very careful in evaluating various unix flavors... There are some major differences in the way the big SVR4 vendors implement many pieces of the operating system.
You'll probably be looking at four or five versions of UNIX:
- Solaris
- AIX
- HP-UX
- Linux
- Irix
Of these, my experience with any Unixes other than Solaris, Linux, and Irix have been awful. Stay as far away from HP-UX as is possible. AIX is crufty and the machines that it runs on are generally rather slow (despite IBM's claims). Irix isn't very stable, but it's a dream to use. Linux and Solaris are very easy to configure and administrate.Another consideration for you is whether or not the applications you use have been ported to the other versions of unix. Many application vendors only port their software to certain versions (i.e. Oracle, Informix, etc.)
Granted I'm not a unix admin guru, but my experience is that if you've got a unix that works reliably with little problems under your load stick to what you've got.
Each unix variant has its own little quirks that depending upon your users, and you, might be and issue.
For example, HP-UX has some quirkiness about how it handles busy disks and large file copies (where the file being copied is a substantial percentage, like 80-90% or more, of the FS buffer) all IO on the system stops. For busy disks you can get physical volume errors where disks are going offline under extremely heavy load.
Solaris on the other hand handles these particular case easily with much less disruption to service and users.
we had multiple OSes to support.
We didn't have the luxury of 2, no . . . we had somewhere between 10 and 20 different versions of operating systems, that is if you include different revisions, etc.
we had everything from SCO to Solaris, to NT 4 to 2k, it was nasty.
The company had bought out a bunch of little ISPs and just threw all their boxes in the racks and made us try and get em all on the network.
Many of these were bought out ISPs and the admins were fired, so of course half of em had no passwords, and a bunch had all kinds of nasty little quirks.
I would say stick with no more than 2 versions at a time, maybe 3.
Different distros have their strong points and weak points, so balance it that way. There is not much of a learning curve unless you have like Solaris and Redhat and BSD in the same building.
Then you start forgetting which system commands work where because you log into em so frequently to do different things.
Its really not an issue of learning curve, its more an issue of annoyance.
the best recommendation I have is to make scripts to do the simplest tasks, that made things so much easier for us in our situation.
Where I started, we had five main types of unix running (SunOS, HP-UX, OSF/1, AIX, and Linux) and multiple revs of all of them. It was trying at times, sure, but if the admin team is able and willing to think about things and isn't afraid to make mistakes, they will get the job done.
Easilly the number one cost is admin time to learn all the tricks necessary to get the job done.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
If the system administrator typically uses "UNIX" configuration tools, like "useradd" then the differences will be minimal, but if some AIX user uses "SMIT"("SMITTY") or the Solaris user uses "admintool then they will be confused and frustrated. AIX is actually a pretty good system, but it is really weird in that it is a UNIX system that the AIX culture uses Mainframe terminology with: "IPL from the DASD", and Solaris is weird because it leaves stuff out that makes no sense. Adding users doesn't install a ".profile", but a "local.profile" that some user that can barely logon is supposed to figure out how to fix later, and "vt320" is still an unrecognized terminal type after 15 years. I personally find Solaris to be one of the most frustrating because all of the tools are half assed, and I get tired of fixing Termcap, Terminfo, /etc/skel and installing a working user admin tool every time I install a new system. HPUX is OK, but it still has a bit of BSD hidden in the cracks. I can't get used to the fact "/etc/init.d" is in "/sbin/init.d". I find RedHat Linux to be one of the most complete with the fewest bizarre idioms, a nice mix of modern and traditional. (This is where the Debian user's shout at me, but I think it's convenient that "X" is configured by default.)
Lots of people have mentioned the various sources of additional costs that can come from having a multi-vendor system environment.
There are potential savings as well:
1. Better rounded employees will be better able to assess the benifits subtle differences in technologies for different applications.
2. Ability to attract good people with established skills on one platform who want the chance to transfer those skills to another platform.
3. *ability* to scare vendors when necessary into giving you a better deal because you already have in house expertise on competing systems. This can be very valuable when negotiating upgrades, new systems and renewed maintainance contracts. Just be careful when and how you wield it. If you are too heavy handed, they may just decide that they are going to loose you and try to milk all they can from you during the transition. It is probably best as a subtle threat wielded when trying to do a deal with them at the end of a tight quarter when their sales team is driven more by tactics to maximize short term revenue at the possible expense of strategic influences on pricing.
I am in the process of rebuilding many of our "legacy" SGI, Apple, and even older Sun systems with Debian. Fewer security holes, homogenous and simple to manage (especially with apt), fast and lightweight - and runs on practically everything we have.
Basically, just choose what you feel is the best server offering (because of price, construction quality, hardware support, and track record), and once the initial install is done, no one knows the difference. :)
A government is a body of people notably ungoverned - AC
It's NEVER cheaper to be multi-platform. More flexible, yes. Right platform for the app, yes again. Cheaper, no. The overhead of managing multiple flavors is large. It matters not who you have for sysadmins, or how capable they are. Patch management, change control, binary compatability, backups, security management, OS upgrades, service contracts, hardware compatability, etc. are all issues that cost you more. You end up having to do the same work over and over for each flavor. Been there, done that.
A TRIVIAL example would be changing your IP address space. Each flavor maintains it config in a different way. It doesn't matter that you know how each one differs. You won't be able to write a simple script that just makes the changes (it would be a complex script if you even chose to do it via script. Or you would write a script for each platform. You would probably end up doing it by hand.)
Another trivial example would be initial system load. With solaris for example, you setup (and maintain) a jumpstart server. When you get a new machine, an hour later you have a complete environment setup with all your customizations, up to date patches, etc. without hardly lifting a finger. Now add IRIX, Redhat, debian, freebsd, aix, HP, OSX into the mix. See the problem?
The list of examples of all the additional costs associated with maintaining multiple flavors is virtually endless.
You basically have it backwards. It's cheaper in the SHORT run. You can shop based on price. Initial setup isn't that bad. It's the LONG term maintenance costs that get you. It's ALWAYS easier / faster / cheaper to only have one platform to maintain.
Buddy, pour yourself a nice warm cup of STFU and go hang out with yourself in the corner.
Knowing that (as an example) AIX has a pretty self tuning kernel, that Solaris has a modular kernel, and that UnixWare needs a recompile (relink) for any minor changes forces the admin to think about the operating system instead of just drooling on the keyboard.
The biggest differences are still SysV vs BSD. Understanding those is vital in a mixed OS environment. Beyond that, there are usually differences in disk layout (and filesystems), but they just add to the rich diversity that is my favourite OS.
At my work, we are big users of Solaris, but because we develop software for multiple platforms, I've also had exposure to AIX, UnixWare, Sequent Dynix/PTS, HP-UX and DRS/NX. These days we've dropped Dynix/PTS (EOL anyway I think), HP-UX (too expensive for our customers), and DRS/NX (dead?) but we're looking to port to OpenUnix 8 and Red Hat Linux, so things are still pretty mixed. I just think it's a shame that I don't get to work with HP-UX and that Unixware is dying (yes - I like it!).
We also port to NT/2000, which is good to compare - it's a nightmare to work with when used to UNIX.
How hard is it to suck your own dick? Give it a try and report back.
You don't give much background information. If you are talking about a shopt hat has one or two mid-level solaris boxes and is looking at a new server for like, some application you run.. sure, look elsewhere.
IF you are talking bout BIG servers, and some heavy investment into infrastructure..
Let's say the only change you should make is to another vendor for the future.
It's not about whether not you can administer one box or the other... it's about simplicity. Don't make things more complicated than they have to be.
Some thoughts about previous post topics and how they relate to my own personal experiences:
- Backups of dissimular Unix flavors would not be a problem, because we use Veritas Datacenter and a single 30 cartridge 2-headed tape jukebox.
- Our developers hardly understand UNIX, and the sysadmins maintain the scripts in production. So bouncing between linux and solaris is no real big deal for them
- General admin isn't too much of a problem. NIS+, NFS and Samba make sharing directories and administering users fairly easy. Central print spoolers using lpd and Samba, plus imaged builds make maintenance fairly simple.
- Security is the biggest issue. I can skip most patches for Sun and Linux unless there is a specific problem, but we have to watch and install the security ones. Sun packages and RPMs are easy to install remotely, but sometimes the fix is to chmod some file, so we either write a script or visit each machine. SSH makes this bearable.
So, my take on your question is that it will depend on the quality of the system admins on how much work it will be.I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
The one above is gorgeous, but the one you posted makes me sick. I mean, how old is she? 12? How did anyone get her to dress like that?
So, you want to know exactly how hard it is to support multiple Unices, eh? To quantify, your answer is 52 Rockwell. Let me know if you'd like it measured by another method, such as Brinell, Scleroscope, Tukon or Vickers.
We have Linux and HPUX (used to also have Irix and Solaris). No real problem for the most part.
Usually what I find myself thinking is "why can't I do this/that on HPUX". Until we went to HPUX 11, the only thing HPUX used PAM for was CDE - now the whole system uses it. They've added something called cifsclient, which does the same as smbmount. You can even install ipfilter's into the OS now.
So using the actual OS isn't that bad - a few differences in the way some things are done here and there. Hardware can be night and day though.
This is a reasonable question.
"walt-sjc" has a great response and has been in this boat before.
My recommendation is to be careful not to kid yourself, adding another unix
(does anyone remember Eunice?) to your production environment is akin to
adding another OS, which is akin to adding people.
You might ask the opinion of any person who thought they had a nice simple homogenous Sun shop and then went through the BSD->Solaris transition.
For example many of your tools that autonomously update configs/etc may now need a person in the loop.
Easy: License management, home-grown admin scripts, home-grown bins
Harder: Backups.
PITA: Crash recovery
Expensive: Tracking OS & Application patches, security. Chaseing hardware. Maintenance agreements.
The last 2 categories can make "another unice" approach the cost of "another
OS".
These obviously aren't reasons not to do it, just reasons for your management
to go in with your eyes open.
I'm saying it's more expensive in the short run because I'm assuming they take the time to set up the scripting and automanagement at the beginning. Once they set it up adding boxes from the same vender is simple. But yes, I will agree (as you pointed out) for some problems having multiple OSes can be a pain. I would submit though that being locked into one vender can be just as costly and painful. Look at the whole Microsoft debacle when they decided to change their licensing and strong armed billions of dollars out of Microsoft only shops.
All the staff will become stronger as a result of
having an additional flavour of Unix.
Having only one vendors' implementation of Unix weakens a staff. They become blinded by minor differences rather than appreciating the power, depth, and flexibility of Unix.
aem
-a.e.mossberg
First thing I do when I start administering Unices is to install GNU utilities. At least this will lessen your headache.
Its simple. If you standardize across a platform, any programming or maintenance work becomes just that much easier. Need to write a new fubar script? Well, would you rather write it for 1 platform or 10? Would you rather debug 1 platform or 10? etc... etc... etc...
/. questions?
Can't we add an age/experience limit to the ask
Anonymous posts are filtered.
I use nothing but open source but my god this thread
might as well have been written by the marketing
team in redmond.
THIS is why a MS salesman has an easy time talking
managers into dumping unix for NT/w2k/xp.
Wake up people. Unite or be MSsimilated.
Identical O/S and a super powerful oo scripting language everywhere for stiching the apps together.
Only half in jest, but it's a viable solution none the less.
I install bash, python,gcc,emacs on any machine I have to work with.
Of course you still have to deal with system scripts and with propretary admin tool, but at least you have some common point.
Ciao
----
FB
Where i work we have about every UNIX available running. but our main focus is on HPUX and Solaris.
:))
...
first, use your brain!! unix admin are normally not stupied. and you should be able to figure out the _main_ differences between all variants quickly.
second, get a small test machine, just for the purpose of testing. (test machines always come in handy, get your one now!
third, you have a support contract on those machines right? don't be ashamed to open a support-call for some stupied question (if you cannot find it on the (use)net/manuals first)
forth, consider training, but do NOT go to the basic training courses, they will teach you nothing new there! go to: performance tuning, troubleshooting (this one is always good),
fifth, be carefull with your shell scripts, not every unix has the same commands in the same place, but you should be able to script around this.
at work, we all have our focus area, i'm the solaris/linux guy, sombody else has most HPUX expierence, another guy AIX, etc... needless to say we learn a lot from eachother. maybe your boss should consider hiring somebody with a lot of expierence on that platform so you can all share knowledge between eachother.
On a long enough timeline, the survival rate for everyone drops to zero.
As some comments have already pointed out configuration changes on different Unices will be a pain. You need scripts which distinguish between them and this can be quite messy with all the clauses. cfengine makes this a lot easier and also keeps the configuration files readable. In addition it has some nice file mangament (moving, archiving, deleting, permissions) and text editing functionality. It also allows you to deploy changes from a central workstation to hundreds of clients with ease.
from the to-stupid-for-words dept.
It's a great thing to do, as long as you don't run any proprietary software.
We administer 3 different OSs here (Solaris, Debian and OpenBSD), and the additional learning, experience and perspective we get is really valuable.
When you have to consider that your code will run on multiple OSes it forces you to consider what you really want to do. You need to pay attention to where the pedal touches the metal, and this is always valuable. It stops you making arbitrary assumptions.
The only problem is proprietary software - this generally sucks anyway and the real evidence is portability.
Easy portability is a sign of good software - abstractions were made in the right places, and concern for multiple target environments was considered from day 1 (even on one OS you can get a lot of different configs).
You can't port most proprietary software yourself, since important bits you need to know about are kept sooper sekrit. Even if it isn't, it's often so crap it's not worth the effort.
I wouldn't believe many vendors claims of portability - the devil is in the detail, and unless you can get in there and fix the odd stupid assumption yourself, you are going to spend the rest of your life on the phone to clueless vendor support monkeys.
& maybe a different phone number for ordering parts.
A mechanic that can't cope with working on different vehicles wouldn't even pass their apprenticeship.
I wouldn't even find a real Ferrari challenge over a Holden of Ford Falcon of the same period. Mind you it would take a lot longer, complexion just adds more time.
Really doing a clutch on a old HQ Holden with a 3 on the tree manual isn't much different than doing one on a slotted 5 speed Hewland transaxle of a Ferrari of the same period, say a Dino, except that there's a lot more bolts & screws to undo & redo to get to the clutch.
Hmmmm. It's a little problematic that you only have one flavor of Unix now.
My experience is that managing different flavors of Unix is a lot like porting to different flavors of Unix.
That is, learning to go from the first to the second platform is often the most difficult step. Then going from the second to the third is slightly easier, etc.
Level of difficulty = 1 - exp(-n)
Thus, for your situtation, the difficulty of migration is going to be directly related to how similar the 2nd platform is to the first.
In the old days it was easy to distinguish the BSD flavors from the SysV flavors as a significant learning hump that had to be overcome.
"Provided by the management for your protection."
I swear, when I read that title it looked like "How hard is it to manage Different Uncles?
13 year old white supremacists are shitty web designers.
If you have to, or want to, deal with multiple unix flavours, get the third edition of the Unix System Administration Handbook. It has yet to fail to provide me with an answer when I get stuck on a cross-platform issue.
What Would the Fab Five Do?
where can you run killall -
various linux - kills processes with that name
aix, hpux, true64, solaris - shuts the machine down
perhaps people ought to stop using root when they don't know which machine you are on?
You will get twice as many freebies :)
You never learned not to post a response to your own post. Dumb fucker.
For drivers you can split the driver in two peices. The part of the driver that interacts with the kernel / OS. This should have about 5 functions: READ, WRITE, STATUS, OPEN, CLOSE. Then you can write the second part of the driver to call these generic functions putting the absolute minimum in the functions, but also putting the parts that are OS specific there as well.
Only 'flamers' flame!
As a senior systems engineer from a similar organization (Carrier1 (FALCO!)) I can say there were no issue running a multi unix environment, and I've never had any issue with it at any of my previous companies (nor have any of the engineers I've worked with).
:). I had Mac OS X, GNU/HURD, Debian and Solaris all on my desk at one point.
:)
At Carrier1 had FreeBSD, Red Hat & Debian Linux, Solaris 9 & 9, HP-UX, even GNU/Hurd and Mac OS X (well, on *my* system
The only problem I've ever had is the fairly trivial (?!) one of getting the command flags right - stuff like the 'ps','route','ipchains, 'ipfw' and 'ifconfig' commands syntax being different, the different flags for package management tools, that sort of thing.
I quickly came to realise that it's not possible to remember all the flags for all programs and remember the best way to do something on a particular system if you are busy all the time, things just seem to seep out. This happens if you are spending lots of time programming or in meetings or working on large projects - in which case you might not touch one type of system for months (until there is a problem with it), at which point you find your self quickly reading man pages and referring to Google a lot. All you need to do is remeber what's improrant, especially things you'll need for troubleshooting, and not worry about the rest - it's enough to know about tool's like Solaris 'ndd' and Linux's 'mknod' and what they do, if you need to remeber exactly how to use them in a given instance you can refer to man pages, O'Reilly Books or Google (which I often find the fastest).
Staying current, reading Freshmeat everyday, installing and configuring new Unixes and new & un-familer packages regularly, being on mailing lists and reading Slashdot are good ways to stay up to date - the more you know the less likely you are to run into something completely unexpected. If your resourceful (which you should be as a Systems Engineer) the only real problems arise went you don't even know where to start, everything else is a piece of cake.
Basically, if you really know unix (and are not just a Red Hat Linux or Solaris flunky who has convinced themselves they are Gurus while they still run Windows 2000 day to day) then you won't have any problems.
Oh, and making lame excuses like 'well I need Windows for work stuff' and 'they won't let me run Unix on my desktop' DO NOT wash - they are just that - excuses for lameness.
I have been for job interviews and been introduced to guys who called themselves (literally!) 'Unix Gods', yet they had only ever used Solaris - if you have any of those you are in deep shit right now. [ Needless to say I ran a mile! ]
Most people fall somewhere in the middle of those two, you'll probably only have one or two decent guys, if your lucky, though if you need to ask you are very possibly in trouble already!
YMMV.
At our site we have HP-UX, OpenVMS, AIX, Solaris, and probably one or two I don't know about that our Midrange Systems people manage. There are three of them to service 15 or so major 24x7 medical-related systems. They can do it because they are darn good, we tend to dump the apps support on the apps vendor by contract, and the management doesn't interfere or hobble them with various insanities. Of the three the good admin one is most important, although having good management probably helps retain the good techs.
They say they like AIX best due to the ease of admin.
________________________________________ History Must Not Fall Into The Wrong Hands ___________________________________
As has been pointed out, low-level commands like creating disk partitions differ a lot between different flavors of Unix. And that is one of the first things you'll do after the machine is plugged in.
I was struck by the words "another BIG server" (emphasis added) in the original post. If by big you mean this is a machine that can do domaining, like a Sun Starfire or Starcat on an HP Superdome, you need to send someone to the manufacturer's training on that. If you're spending this kind of money, the application that runs on the box will be critical enough that you can't afford to have people learn by breaking it. In fact, you need to send two people, so the first can go on vacation.
Even without that, someone has to spend the time to monitor mailing lists for security patches, get the patches, test upgrades, and the like. There are new phone numbers to call when something breaks, new service people to get to know, and more contracts to keep track of. And what if your centralized administration software (monitoring, password syncing, QA, or whatever) doesn't work right on the new box? Getting the first of a new OS in house is a very expensive proposition, because everything takes a lot longer than it does on the old, familiar machines.
IMHO, the single most significant difference between different vendors' offerings is the difference in what happens before you get to the OS. If you have a dead machine and want to run firmware diagnostics, or boot a different OS image or whatever, then the different platforms are almost completely proprietary.
There's the Intel stack - with the MBR outside the disc partitions, and the Bios limitations with 1024 cylinders, and the need for a tiny LILO or GRUB to get stuff from the filesystem.
There's the Sparc stack - with the boot blocks inside the disc partitions and Firmware capable of booting from the network.
I had brief encounters with the HP K-series stack once, and had to bluff my way through somehow.
While the differences in installers, and patchers, and package management are all significant, the ability to use the firmware layer effectively when the machine won't boot normally and the PHB is looking over your shoulder is the main difference between platforms.
Dunstan
The last scintilla of doubt just rode out of town
It's ashtonishing how easily (and fastly) history repeats.
Of course monoculture is cheaper and more effective, that's why do we have monocultives in first place!!!
But of course we do know too why it's bad. Even for badly brain-damaged pointy haired people it begins to become obvious why in fact Microsoft monoculture is bad; for the sysadmin, the youngest sysadmin, it's a question of knowledge: "I know it's bad, I've eyes and see Microsoft, I have memory and remember reading about IBM"... the seasoned sysadmin just points his finger to the pointy haired stuff and says "I told you. Me, veteran of the Open Platform Wars".
Also, the longer you know one flavor of UNIX, the more likely you are to call any new flavor you encounter ``braindead".
Except when it comes to SCO. Trust me on that one.
The longer you know one flavor of UNIX, specifically SCO,
then you are NOT likely to call ANY new flavor "braindead".
Is SCO the UNIX that Microsoft/UNISYS has the way out of?
Is NT (or whatever the current version is) "braindead" compared to SCO?