Text selection improvements: Multiple text selections can be made with Ctrl/Cmd; Double-click drag selects in "word-by-word" mode; Triple-clicking selects a paragraph.
I support 300 servers for a large financial institution. The cost of any one of them being down is up to $500,000/hour. AIX is our solution of choice. I love Linux and use it exclusively at home, but Linux simply isn't ready for this level of responsibility-- yet. We are starting to put some lesser-critical applications on Linux and we have it as an OS offering in our UNIX space, along with Solaris.
Some things that I'd like to see Linux achieve before it's really ready for prime time: * Achieve a mature high-availability model. With the kind of uptime we require, I need a clustering solution that is very reliable and eliminates all single points of failure * SAN support. SAN is still a relatively new (10 years or so?) technology. There are still quirks to work out and even Solaris and AIX occasionally have issues with them. It's a complicated technology. Add "Synchronous Data Replication" features and it gets more complicated. * Drivers, Firmware, and Microcode. Because of the diverse hardware Linux runs on, I don't think enough attention has been paid here.
I work for a large bank; we have had very aggressive efforts to get everything patched in time and have spent thousands of man-hours getting this done.
Bear in mind that all of this becomes ever-more difficult when you have to schedule the patching, follow change control process, etc... even if it doesn't require an outage.
Some of the items that are involved that I haven't seen much discussion on:
- Solaris
- AIX
- HP-UX
- Java
- Oracle
All of these need patched; java is particularly troublesome because there are so many instances it spewed everywhere.
I work in a large financial institution; our mission-critical systems are either AIX or Solaris, with heavy emphasis on AIX.
AIX seems difficult for many because it is (IMHO) so much more mature than anything else out there. Clustering, performance tuning, etc. are decent with some other vendors (i.e Veritas Cluster on Solaris). Smit makes things elegant and simple, but also lets you (Esc-6) see what commands it is running in case you want to script things.
You have to consider so many things that other OS's really neglect- hardware firmware/microcode versions, patching, etc. AIX really tackles all of them, and in a mature way.
I don't think there are that many options for a very good midrange operating system when you are talking about $500k/hour downtime. For me, in order- AIX, Solaris, and HPUX.
I access my files wirelessly through the router, and I use a cron job to have rsync make a remote copy to an off-site server.
If I lose the drive, I have a backup copy; if I'd have a disaster (house burns down), I have a copy, and if I need to take my data with me, I can just unplug the drive and go.
- John
Re:Sun - Corporate mismanagement at its finest
on
Sun to Cut 5000 Jobs
·
· Score: 1
Okay, in the low end (4 cpus and under) Linux has made some inroads, but being related to a Sun employee I know for a fact that at the midrange and high end they are destroying HP and Dell in our market, and IBM is holding their own with AIX and Linux. When Linux is as robust as Solaris on Sparc we'll talk, but no matter what the fanbois say it currently isn't. Eighteen year old kids running OpenSolaris on marginally compatible hardware don't count
I agree. My group manages thousands of midrange/high-end servers and we generally use Solaris as our first choice. To me, they seem to be one of the easier to use commercial Unix products, AIX coming in as a close second IMHO. We're still rather timid with regards to Linux (RHAS). Linux is great for some things, but there's still a lack of comfort when your application costs $500k per hour of downtime. The high-availability that we achieve with Sun hardware and Solaris is more baked at this point in time.
Also, let's not forget support- it seems like this is so-often overlooked. My understanding is that even before Solaris went open, the cost of the OS license was trivial when compared to having good backend support. Again, with critical applications hold huge downtime costs, it's rather important to be able to get to tier-3 engineering when problems do inevitably come up.
To me, whether or not you use sudo depends on the server and what you are doing. I'm much more likely to act as root on a development server than a production one. If I don't know a lot about the server I'm on or I know it is very critical, I'll use sudo more diligently. However, if I'm on a server doing something I've done plenty of times before, I might 'sudo ksh' to perform my work.
I know SA's that shell out to root without ever incurring a problem-- they've learned the hard way in the past and now have the judgment and experience to be careful. Depending on what's being done, I may do an echo `dosomething here` before I run the command to make sure any variable interpretation occurs as expected.
I also know an very experienced SA who has zeroed out/etc/passwd by misprinting a character. Sudo doesn't protect a bad misprint- it hopefully helps the user identify it before it's too late.
For me, the bottom line is whether the SA needs the reminder to double check his/her work before executing a command. For me, sometimes I have a comfort level to not need the reminder; other times I know that I need to be more careful.
Slashdot Mirror
I support 300 servers for a large financial institution. The cost of any one of them being down is up to $500,000/hour. AIX is our solution of choice. I love Linux and use it exclusively at home, but Linux simply isn't ready for this level of responsibility-- yet. We are starting to put some lesser-critical applications on Linux and we have it as an OS offering in our UNIX space, along with Solaris.
Some things that I'd like to see Linux achieve before it's really ready for prime time:
* Achieve a mature high-availability model. With the kind of uptime we require, I need a clustering solution that is very reliable and eliminates all single points of failure
* SAN support. SAN is still a relatively new (10 years or so?) technology. There are still quirks to work out and even Solaris and AIX occasionally have issues with them. It's a complicated technology. Add "Synchronous Data Replication" features and it gets more complicated.
* Drivers, Firmware, and Microcode. Because of the diverse hardware Linux runs on, I don't think enough attention has been paid here.
- John
I work for a large bank; we have had very aggressive efforts to get everything patched in time and have spent thousands of man-hours getting this done. Bear in mind that all of this becomes ever-more difficult when you have to schedule the patching, follow change control process, etc... even if it doesn't require an outage. Some of the items that are involved that I haven't seen much discussion on: - Solaris - AIX - HP-UX - Java - Oracle All of these need patched; java is particularly troublesome because there are so many instances it spewed everywhere.
Mod parent up.
I work in a large financial institution; our mission-critical systems are either AIX or Solaris, with heavy emphasis on AIX.
AIX seems difficult for many because it is (IMHO) so much more mature than anything else out there. Clustering, performance tuning, etc. are decent with some other vendors (i.e Veritas Cluster on Solaris). Smit makes things elegant and simple, but also lets you (Esc-6) see what commands it is running in case you want to script things.
You have to consider so many things that other OS's really neglect- hardware firmware/microcode versions, patching, etc. AIX really tackles all of them, and in a mature way.
I don't think there are that many options for a very good midrange operating system when you are talking about $500k/hour downtime. For me, in order- AIX, Solaris, and HPUX.
I just finished a little project for this; I have an external USB hard drive connected up to my wireless storage router (WRTSL54GS).
I installed OpenWRT http://www.openwrt.org/ firmware with rsync & samba. See http://wiki.openwrt.org/rsync-usb-sambaHowTo for info.
I access my files wirelessly through the router, and I use a cron job to have rsync make a remote copy to an off-site server. If I lose the drive, I have a backup copy; if I'd have a disaster (house burns down), I have a copy, and if I need to take my data with me, I can just unplug the drive and go.
- John
I agree. My group manages thousands of midrange/high-end servers and we generally use Solaris as our first choice. To me, they seem to be one of the easier to use commercial Unix products, AIX coming in as a close second IMHO. We're still rather timid with regards to Linux (RHAS). Linux is great for some things, but there's still a lack of comfort when your application costs $500k per hour of downtime. The high-availability that we achieve with Sun hardware and Solaris is more baked at this point in time.
Also, let's not forget support- it seems like this is so-often overlooked. My understanding is that even before Solaris went open, the cost of the OS license was trivial when compared to having good backend support. Again, with critical applications hold huge downtime costs, it's rather important to be able to get to tier-3 engineering when problems do inevitably come up.
To me, whether or not you use sudo depends on the server and what you are doing. I'm much more likely to act as root on a development server than a production one. If I don't know a lot about the server I'm on or I know it is very critical, I'll use sudo more diligently. However, if I'm on a server doing something I've done plenty of times before, I might 'sudo ksh' to perform my work.
/etc/passwd by misprinting a character. Sudo doesn't protect a bad misprint- it hopefully helps the user identify it before it's too late.
I know SA's that shell out to root without ever incurring a problem-- they've learned the hard way in the past and now have the judgment and experience to be careful. Depending on what's being done, I may do an echo `dosomething here` before I run the command to make sure any variable interpretation occurs as expected.
I also know an very experienced SA who has zeroed out
For me, the bottom line is whether the SA needs the reminder to double check his/her work before executing a command. For me, sometimes I have a comfort level to not need the reminder; other times I know that I need to be more careful.
PEBKAC