> 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.
Such things are so strange to read about if you come from a Solaris environment... those things are foreign to me. > Not every production system that exists out there > runs > legacy binaries. Yeah, well, what do you do if you have about 2,500 applications already running? The cost of adaptation would be trumendous, not to mention how many hundreds or thousands of man days it would take to get the job done. > When we are the system engineering department and we > need to make these boxes perform with more efficient > code/features. Regular engineering release cycles? > You work in a different environment with different > needs. I don't believe so. Why? Because the methodics we use would be a cure for ad-hoc environments. > 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'. What about "time to market"? Service response? Rapid deployment? I'm able to provide a fully running and configured server or servers, hundreds of them, within a few minutes. Exactly the thing an ad-hoc environments strive for, but never manage to meet. That's my point. > 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. Automated clustering solution? > 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? su - Password: svcadm disable svc:/network/smtp:sendmail pkrgm -n SUNWsndmr SUNWsndmu pkgadd -a /var/opt/abcd/sadm/install/admin/admin /net/software-repo-server/spool/pkg/ ABCDpostfixuser ABCDpostfixlanconfig ABCDpostfix svcs -xv svc:/network/smtp:abcd_postfix online May_16 svc:/network/smtp:abcd_postfix And that's just an *interactive* example; note that no configuration has been performed, just the software installed, and it's running and serving already (preconfigured via ABCDpostfixlanconfig package). In reality, those packages would have been removed, and Postfix packages would have been added by a central software deployment server, with two or three clicks in a web browser. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
