To view parent comment, click here.
To read all comments associated with this story, please click here.
Three...if the systems are properly secured/isolated, rebooting is very very rarely required. Shutting down and restarting upgraded services should be enough in nearly all cases.
To suggest otherwise implies that kernel level patches are required for security or stability. If they are, there are more fundimential problems either with the supplier (regaurdless of type; commercial or not) or with the admin's abilities.
That said, if the admin is just lazy they likely have not properly secured either the system(s) or the network.
Well this machine is on an isolated LAN even within my organization. I presume the fact it has not been patched is a matter of priority, number one, given its extreme isolation and two, the system is fairly stripped down to the bone as it is.
That being said, yeah, if you run a networked system with remotely exploitable kernel flaws, you'd better patch and reboot. And then of course there are the issues (not an issue here) of local compromises as well - people walking by.
Nevertheless, it is a rough, if imperfect indicator of its stability that it continues to do massive data crunching on a daily basis, and has not had to be touched in quite some time. I mean, I rely on it.
What it does not do is have dozens and dozens of simultaneous users nor have to deal with overwhelming network load, so that has to be taken into account.
The CPU and memory are however pushed hard by local processes.
My point in even mentioning this was that the machine has not wedged in over 2 years of 24/7 use; no more than that. No one's trying to win some kind of uptime contest, but as an indicator of reliability, you can glean something from an uptime. It just doesn't say that a machine that has been rebooted regularly is necessarily less stable.
On this subject as per Linux, I have wedged it a few times, but all of these problems were tied to video. Eventually I turned off render acceleration in the X configuration file and it's not wedged once since.
Overall then I've just not noticed any big stability issues with any of these UNIX-like OSes; it would not be a factor - for me - in choosing which to run based on what I know.
What would matter to me is timeliness of security updates (How is this for Solaris? I ran a Cobalt RaQ for awhile - a whole different product line, running Linux - and the timeliness was dismal). Debian had its problems recently...
Then, ease of being alerted of them and applying them would be fairly important. I'd prefer not to have to dick around too much to get them applied quickly.
All of this is of course trumped by what applications you need to run, if it is not a standard cross-platform application like Apache.
And then there's cost. I mean, look, some businesses will spend whatever is asked for in IT, but others will not. Sometimes it's organizational. Sometimes it's a matter of, "We can do this, but not as well, for a lot less money." and sometimes that wins.
There is never a hard and fast rule in business regarding the up-front costs of hardware and software. Sometimes you can say, "Hey I can do this without vendor support for a fraction of the cost on hardware we already have with a free OS" (not so much an issue now with Solaris I guess), in which case sometimes the answer will be yes, and sometimes the answer will be no - no meaning, we require vendor support, and will not deploy a system without it.
My company suggests and recommends Solaris hardware and OS, but tolerates, say, Linux, in certain instances. In two instances we deployed remarkably useful resources because we could do it for (virtually) free. We could not have done it otherwise.
Now with Solaris being free, this consideration changes some.
Three...if the systems are properly secured/isolated, rebooting is very very rarely required. Shutting down and restarting upgraded services should be enough in nearly all cases.
To suggest otherwise implies that kernel level patches are required for security or stability. If they are, there are more fundimential problems either with the supplier (regaurdless of type; commercial or not) or with the admin's abilities.
That said, if the admin is just lazy they likely have not properly secured either the system(s) or the network.
I have had this argument time and time again fact is best practice in well maintained environments is regular quarterly reboots if possible. Truth is you don't have to reboot Unix but you may work in an environment that is not architected for proper maintenance and/or you user base is unreasonable with their expectations of uptime and availability.






Member since:
2005-07-28
I do not administer those systems, number one.
Number two, these are internal systems.