--- a b <[EMAIL PROTECTED]> wrote: > > > No worries. I am sure open positions in your> > respective companies are few. > Not sure what you meant by that. There are tons of > open positions in my company, worldwide to boot.
I meant Solaris positions. > > > Why not? RHEL3 did not use 2.6. RHEL4 is stuck > with> 2.6.9 + certain backports. If you need some of > the> latest features, you use Fedora. Given that a > release> comes with at least one year of updates, I > do not see> a problem especially if you have a > system that> automatically builds the staging > box(es) and tests for> problems, changes in expected > behaviour and breakages. > This must be a Linux-specific thing. > On Solaris we don't worry about which kernel rev. > we're running; with a few exceptions over the years, > they've all been stable. Solaris API and ABI are so > stable that it's never an issue for an average > sysadmin. For system performance and sometimes stability in certain scenarios due to bug fixes. We do not care too much about API/ABI stability. Much of what we need either comes with the distribution or needs to have a internal package made. Not every production system that exists out there runs legacy binaries. > > I never did get the > "look-ma-I'm-runnning-the-latest-and-greatest-2.6.x-kernel > thing". I mean, unless you're kernel hacker, what's > it to you which kernel revision you're running? > So long as the system is doing his designated > function, i.e. providing a stable service, and so > long there aren't any security fixes to apply, why > do you even care? It's the job of system engineering > dept. to worry about such things... When we are the system engineering department and we need to make these boxes perform with more efficient code/features. > > To me as a long time Solaris/IRIX/HP-UX guy, the > whole thing with the kernel rev. is just bizzarre. You work in a different environment with different needs. > > > yawn. too much work to keep updated. With Fedora,> > beyond the initial staging of a new release, > testing> and deploying updates are trivial. > Did you ever read any of Dennis Clarke's posts and > blogs about putting some Solaris server in EONS ago > somwehere, and people just forgetting that it's even > there, because it just keeps on serving and serving > and serving? If you didn't, perhaps you should. He > has some fascinating stories. I had perfectly fine stuff running on FreeBSD that won't crash. The problem was, it was really slow in performance and in the end, I had them all ripped out and replaced with Linux to get twice the deliveries and get more smtp transactions handled. We obviously do not care about 'stability'. > > And Dennis is not alone in this experience. This is > something we take for granted in a Solaris > environment. Very nice. Not impressed however. We had one or two linux boxes like that. They have been running for over two years without a reboot and we were worried that they would fail to boot if they did crash or suffered a power loss especially since they were the boxes that only ran an old copy of forum software. > > Like I wrote before, the whole lots of noise about > updating and patching is simply bizzarre to me to > read about and watch as a Solaris consumer. I guess > people just assume Solaris is going to need the same > kind of babysitting as Linux. What else am I > supposed to conclude from reading what Linux people > complain about? The current way software on Solaris is managed, oh yes it will need plenty of babysitting in our environment. For example, sendmail was patched to add mysql table support. sendmail, being the security exploit prone piece of software that it is, gets frequent updates that fix security holes and some of them are root exploits. You can bet that any sendmail 'patch' for Solaris 10 will break our system. Would we dare automate security fixes? The current software management via patches is not transparent and a pain to keep an eye on because you have to look to find out what comes in the patch. We dare not automate any updating for security holes because who knows what it will clobber? Whereas with apt/dpkg or yum/rpm, we are not worried at all and we can enable updates for the system without fear of having our modified sendmail clobbered by the sendmail from the distribution provider while we prepare our own modified package of the updated sendmail. No, Solaris 10 would need more babysitting in our environment than apt/dpkg or yum/rpm managed Linux. In fact, I do not see why the apt/dpkg or yum/rpm way of things would make Solaris 10 any less manageable but since it will not be accepted for Solaris 10, I hope for one of them in the Sun OpenSolaris distribution. > > > Solaris != OpenSolaris. Solaris 10 is not there > yet. > > What do you mean by "not there yet"? > Solaris 10 is THE choice for deployment in mission > critical and production environments. You are taking this out of context. This part of the thread was about Solaris 10 have its source available too which is not the case at the moment and therefore 'not there yet'. > > Nor does they exist a commercially supported> > OpenSolaris distribution with some of the things > some> would like to see irrespective of people in > banks> think. > That you can forget. Banks want (and get!!!) > super-stable environments, and OpenSolaris will > never be a choice, simply because it inherently > can't provide that kind of stability, being a code > base in constant development. Thank you. Which is why I like the idea of Project Indiana catering to others besides banks. You can keep your Solaris 10 and we will take OpenSolaris when it meets our requirements. > > > I wonder what Linux distribution certain banks in > Hong> Kong use. Debian!? > I don't know, you tell me? > I do not know. I only saw ads from some banks looking for linux skills. Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ opensolaris-discuss mailing list [email protected]
