Solaris Machine Shut Down After 3737 Days of Uptime

An anonymous reader writes "After running uninterrupted for 3737 days, this humble Sun 280R server running Solaris 9 was shut down. At the time of making the video it was idle, the last service it had was removed sometime last year. A tribute video was made with some feelings about Sun, Solaris, the walk to the data center and freeing a machine from internet-slavery."

Comments

So what did it do all that time?

[cod3r_]

A *nix machine being idle for 3737 days is not all that interesting.

Re:So what did it do all that time?

[Anonymous Coward]

Somewhere at my last job, there was a Solaris 8 machine with over 4000 days uptime, that everybody hated to do anything with, but one person loved it and refused to migrate the last service that was still on it to something more modern.

Uptime is irrelevant for an individual server, anyway. If there's fail over (and there should be if uptime is important), take it down and update the kernel for security reasons, who cares?

Re:So what did it do all that time?

[crutchy]

If there's fail over (and there should be if uptime is important)

i agree... if you're responsible for a single server performing a mission critical function with no fail over, you may as well just fire yourself

Re:So what did it do all that time?

[h4rr4r]

Just get it in writing.
Been there done that, when it has to come down for hardware failure or something like that you can show you tried to get a backup machine, you tried to do things right.

Re:So what did it do all that time?

[Anonymous Coward]

No, it was idle "only" since day 3509 (served as a hot backup if we had to restore the service from the new machines).

Re:So what did it do all that time?

[Nerdfest]

If you use something like Ksplice, you can install the kernel security patches without rebooting, although I don't think they were doing that here. I'm so disappointed that Oracle bought Ksplice.

Re:So what did it do all that time?

[Anarchduke]

an even more important part of your job then ensuring failover. that is, covering your ass.

Re:So what did it do all that time?

[kasperd]

mission critical function with no fail over

It is surprisingly hard to guarantee data integrity when doing a fail over.

If you want to guarantee a system keeps operating and maintains data integrity when a single computer fails, you need at least another three computers that are still running with no failures. There is a mathematical proof for this.

If you want to go lower than four computers, you have to make assumptions about how the failures behave. And if just one computer fails in a way that does not match your assumptions, the system will fail.

If you do decide to go with the four computers required to handle a single failure, the protocols to ensure they agree on the current state of your data are quite complicated. The protocols have to be non-deterministic. That's another proven fact. No matter how many machines you throw at the problem, a deterministic protocol cannot handle even a single failure.

You can get around the non-deterministic requirement if you make assumptions about the timing of communication. But you'd slow down the system unnecessarily because you'd have to wait for the maximum time you assumed packet delivery could take on every operation, and if the network was slower than you assumed, the system would fail.

Knowing how difficult fail over can be, it is no surprise that sometimes it is decided to not bother with it and instead hire an operator, who you assume can make everything be ok as long as you have backups plus spare hardware ready to put in production.

Re:So what did it do all that time?

[rickb928]

Yup. And running a full marathon is pointless and irrelevant - any one could run 26.2 miles on a couple of months, half a mile at a time.

Re:So what did it do all that time?

[Hatta]

If you want to guarantee a system keeps operating and maintains data integrity when a single computer fails, you need at least another three computers that are still running with no failures. There is a mathematical proof for this.

So you need at least 4 computers to make fail-over work reliably.

Knowing how difficult fail over can be, it is no surprise that sometimes it is decided to not bother with it and instead hire an operator, who you assume can make everything be ok as long as you have backups plus spare hardware ready to put in production.

I only count three computers. The failed server, the spare hardware, and the operator. Couldn't you theoretically automate what the operator does, and break the 4 computer requirement for failover?

Re:So what did it do all that time?

[kasperd]

Couldn't you theoretically automate what the operator does, and break the 4 computer requirement for failover?

When I said "who you assume can make everything be ok", I was not trying to imply that the assumption was correct. Maybe I should have made that a bit more clear.

The operator is facing a potentially impossible task. The backup may not be entirely up to date, on top of that the faulty computer could potentially have send corrupted data to the backup.

Re:So what did it do all that time?

[dkf]

[There go the mod points]

Uptime is irrelevant for an individual server, anyway. If there's fail over (and there should be if uptime is important), take it down and update the kernel for security reasons, who cares?

Not all critical services are necessarily internet facing. I know of someone who had an application that ran continually for over 10 years, highly business-critical (master video stream controller for a TV network) and with very fancy hardware attached that it was tricky to replicate. The hardware was gradually updated over that decade, as was the code of the application (dlclose() FTW!)

Re:So what did it do all that time?

[Anonymous Coward]

Id be more interesting if it was an 8088 left on since 1980s.

Re:So what did it do all that time?

[dkf]

[Button press fail]
The hardware was gradually updated over that decade, as was the code of the application (dlclose() FTW!) but the application process genuinely ran without stopping for the whole of that time. The guy who wrote it is one of the most careful programmers I know; the design brief definitely was for a system (hw+sw) that could do that sort of uptime.

All of this would be OK except the author also used to get dragged in to support that code from time to time, sometimes really inconveniently...

Re:So what did it do all that time?

[kasperd]

Excuse me? It's *expensive* yes, hard? Not really.

Most problems gets easier to solve, if you have a lot of money to work with. This one is no exception. But you still need software, which can correctly execute a non-trivial protocol. A single software glitch could still take down the system when the same bug triggers on replicas simultaneously. Redundant systems have blown up due to replicas suffering from the same software glitch.

That means either you need the software to be bug free. Or you let four different teams develop software according to the same spec and hope three of the teams get it right. And even if you have enough money, how do you make sure the people you are hiring are the right people for the task?

Re:So what did it do all that time?

[crontabminusell]

Somewhere at my last job, there was a Solaris 8 machine with over 4000 days uptime, that everybody hated to do anything with, but one person loved it and refused to migrate the last service that was still on it to something more modern.

Uptime is irrelevant for an individual server, anyway. If there's fail over (and there should be if uptime is important), take it down and update the kernel for security reasons, who cares?

It's like Cory Doctorow said in When Sysadmins Ruled the Earth:

“Greedo will rise again,” Felix said. “I’ve got a 486 downstairs with over five years of uptime. It’s going to break my heart to reboot it.”

“What the everlasting shit do you use a 486 for?”

“Nothing. But who shuts down a machine with five years uptime? That’s like euthanizing your grandmother.”

Re:So what did it do all that time?

[Ignacio]

If you want to guarantee a system keeps operating and maintains data integrity when a single computer fails, you need at least another three computers that are still running with no failures. There is a mathematical proof for this.

I would like to see this proof. I am not doubting you, I am simply curious about the mathematics involved.

Re:So what did it do all that time?

[AK Marc]

Doesn't help. When my boss lied to my boss's boss (the owner), I had documented proof I was right. My choices were to ignore it, and take punishment for things I didn't do, or prove my boss wrong, defending my position and probably costing me my job. I stayed quiet, found a new job, and left a place where my boss would lie to sell me out.

Proof you are right doesn't help. It hast to be shared and spread long before there's an issue, or you can still end up in an unwinnable situation.

Re:So what did it do all that time?

[AK Marc]

I mathematically proved for a previous employer that redundancy was less reliable than multiple single points of failures, based on the probabilities of failures of the devices and the probability of failure of the redundancy protocols (which were, themselves, single points of failure, in the proposed designs). All the expensive duplicated hardware in the world won't save you if your clustering software chokes.

I went through that after the clustering software corrupted the email database on a weekly basis for a couple months straight. The result was to switch software vendors.

Re:So what did it do all that time?

[TheLink]

The problem is ksplice hasn't been around for more than 3737 days ;).

If you run everything on a "cluster" layer (your apps are not dependent or maybe not even aware of the noncluster layer) then you won't have such problems - you can reboot a node with minimal impact. In the old days the ones famous for uptimes were Tandem and VMS.

Re:So what did it do all that time?

[Almost-Retired]

I'd differ with that. I was fresh on the job, just 2 or 3 months, long enough to get the feeling I would be the scapegoat. The owner came in, and a deal the GM had made in a bar 2 weeks back hadn't worked out, and as the 3 of us were walking to the back of the garage to look at what we had, The GM tried to say it was all my idea.

Wrong, I skipped out in front, spun around and said this stops right here and now, I was just following orders. The owner looked at the GM, looked at me, gave a barely perceptible nod, and started walking again. I didn't get pushed to take the blame again, but I did get pushed in every other way it seemed.

Owners didn't get to be owners without a sense of who's right and who's wrong in boss/employee differences. Tell the truth even if you lose, because if you lose, that job was looking for somebody to do it when you walked in. I'd a hell of a lot prefer to stand my ground if I'm right, and admit it if I'm wrong, and I've done quite a bit of both in my 78 years. Honesty has paid off handsomely several times.

About 2 years later another situation came to a boil, and I was the first one called to the owners office when he arrived. He wanted to know what it would take to fix it. I said 2 things, the gear these people are using is just plain worn out, its been on the road non-stop for at least 5 years, I can't get parts because the parts bills aren't being paid. I need 10 grand in parts, and I can't get a P.O. for more than $200 a month, COD. Hell of a way to run a train. Besides that, the technology has moved on. Its time to upgrade.

His next question floored me, he wanted to know if he needed a new GM. I had to say it looked like he was, at the end of the day, the biggest roadblock to making things run smoothly. Then he had another dept head paged, 3 all told in the next 30 minutes. Years later he said they all agreed with me, so we had a new GM by the next morning. That and $150,000 in new gear put out the fire. That GM didn't work so well either after a couple years, but that's another story I am not directly involved in. The 3rd one is a pussy cat and we sometimes get into very noisy arguments even now, just to entertain the troops. He's a decent man, a motivated manager, but in a war of wits with me on technical stuff, he is unarmed and knows it very very well.

Bottom line to this story is that I had already proved my worth from the 1st day on the job because they had about half the gear packed up to go back to the factory shop, expected 2 to 3 grand each for repairs with a 2 week turnaround time. I canceled that, unpacked them and handed in parts orders at about 10% of that per machine. All were back in service inside of 10 days, half that waiting on FEDEX or UPS.

So it was a question of who was worth more to the person who owns the place. I stayed there 18+ years, have now been retired for 11 years, and the owner and I are still friends.

Cheers, Gene

Re:So what did it do all that time?

[AK Marc]

I'd had enough experience to know that the owner was lucky, not smart (he invested his parents at the right time in a friend's business that made millions, then partnered with someone that knew what he was doing, but had no money to make the business I worked for, and the partner that knew what he was doing sold out and started his own business, making more than the owner who stuck with the original. He didn't know how it worked. He was a salesman, not a CEO, and of course, the GM was a salesman as well.

Then the techies were left doing all the work. We lost a guy who moved for family reasons, and were short handed. I was the head of the tech department, and brought up the short-handedness at my weekly meetings with the GM, and sent emails from those meetings with "open issues". Months documented. At a monthly meeting with the owner, one of the sales guys complained that he didn't have anyone available for his pre-sales meetings, and told the CEO we were short handed. The CEO asked the GM how we were staffed. The GM said "If we have staffing issues, Marc didn't raise them". I said "We are short staffed." When I left months later, the sales team was ordered to stop selling because we were too short handed, and they hadn't filled the other guy, or me to this day, 9 months later.

The owner was way too friendly with the GM, so printed emails or the GM's word, and the owner would trust the GM. It happened before on something else.

I didn't even make it my two weeks notice. The GM had gotten notice of an RMA (he puts himself in the middle of everything and slows it down), but didn't tell anyone. 3 months later, we get a nastygram about not sending back the RMA. He complains that we gave bad service, and implied it was my fault. I walked out of his office, went to lunch, and didn't come back. He can't even be bothered to forward an email he's planning on ignoring, but is willing to pin the fault for not delivering on me. When we were so short staffed, I tried to hire someone, but he'd never sign off. So I jerked applicants around because he told me to hire, then changed his mind. They were just evil. The worst place I ever worked. I shouldn't have to work so hard to be treated ethically. But I've never had good experiences with salesmen.

Re:So what did it do all that time?

[AK Marc]

I've installed ovversized "load-balanced" firewalls so that each was at 20% load, but at least each was working. It'd have been cheaper and as or more reliable to have a single firewall running at 80% load, or a second of the same in failover.

Re:So what did it do all that time?

[AK Marc]

No, I generally do great. That's why it was so hard there, I wasn't used to working at a place I didn't fit in well in.

Re:So what did it do all that time?

[Almost-Retired]

Obviously that place was dying before you ever walked in the door. We all have dreams of making things better, but the first time you were sold out should have been the day you 'went out for lunch' and interviewed for a better outfit. You will never get a good recommendation from a$$holes like that, so why waste your time when we're only allotted so much of it & the only way to stretch it is to go fishing? (I've been told repeatedly that time spent fishing is when that clock is unplugged)

I know, hindsight is usually 20-10 or better. You sound young enough and savvy enough to catch up though. I think I can look back on 50+ years working in electronics and say I've had a pretty good ride for a guy with a grammar school diploma and a GED.

Cheers, Gene

Re:So what did it do all that time?

[crutchy]

best way to justify the job you do is to create work for yourself

in IT you can covertly install a virus, which will have half your users begging to get things back up and running and the other half berating you for not doing your job

the last thing you want to do is increase your efficiency to the point where management thinks you are no longer required or that your role can be filled by a machine or some kid fresh out of school

or if you're a department of defense big brass knob, you need to justify spending billions of tax payer money, so you blow up 2 skyscrapers and scare the crap outta the public so they give you more money to go off and fight the world :)

Re:So what did it do all that time?

[crutchy]

drbd and pacemaker are pretty simple and reliable, imho (not to mention free)

attempting to increase reliability and failing is better (and certainly no less disasterous) than ignoring the risk and failing... at least as far as customers or users are concerned

Re:So what did it do all that time?

[AK Marc]

I shopped for other jobs, then didn't leave until I had replacement employment lined up. I wasn't in a position to walk out directly. I did that once, when I was still living at home. I managed to work in a place where I was sexually harassed. I did walk out and never go back. They shorted me on my last paycheck, but it wasn't worth the fight for a few hundred dollars. Living at home, I had no expenses. Got a worse job the next week (worse - phone tech support), but a necessary one for getting in the door in IT - start low.

Re:So what did it do all that time?

[kasperd]

you only need three computers running a distributed consensus protocol such as Paxos.

Paxos makes assumptions about the behaviour of failing nodes. It assumes a failing node will simply stop sending messages and never send a corrupted message. This assumption is violated if a node for example suffers from memory corruption.

There are two different thresholds for those two models. Allowing for arbitrary failures, the threshold is one third. That means less than one third of the nodes may fail. Once you reach exactly one third, the system breaks down. One out of three is exactly one third, so the system breaks down if one out of three is faulty. One out of four is less than one third, so the system can keep working if one out of four is faulty.

Assuming failing nodes stop responding without ever sending a corrupted message gives a threshold of half. That means less than half the nodes may fail. Once you reach exactly half, the system breaks down. Additionally if a single node has a byzantine failure the system breaks down regardless of the total number of nodes.

won't be able to reach consensus if a network split breaks the cluster into two equal-sized halves

That is true. But if you need to be prepared to handle byzantine failures, it won't help you if the network splits your nodes into approximately equal sized partitions, because you need above two thirds to reach consensus.

One way to see what can go wrong is if you assume you have an odd number of nodes. Then assume one node fails. There will be an even number of nodes left, which you can partition into two equal sized partitions. Assume the network between those two partitions is slow, and the network inside each partition is fast. If the failing node is still able to communicate with each partition, but has a byzantine failure that causes it to give inconsistent answers to the two partitions, it is possible for one partition together with the failing node to reach consensus on one result and the other partition together with the failing node to reach consensus on another result. By the time messages between the two partitions have reached the other side of the slow network, they are too late, because consensus has already been reached.

Re:So what did it do all that time?

[kasperd]

I would like to see this proof. I am not doubting you, I am simply curious about the mathematics involved.

I don't remember which paper the result was in, but I do remember the overall idea of the proof.

The general proof says to handle t failures there must be 3t+1 nodes in total.

It is a proof by contradiction, so initially we assume the nodes can be split into three groups with each node being in exactly one of those three groups. And we assume that any two out of those three groups can reach a consensus without involving the third group. Now we'll prove that under those assumptions, the system breaks down.

So we imagine two completely functional groups out of those three, the network within each group is stable, but the network between them is slow. All the nodes in the third group suffer from a byzantine failure, which cause them to send corrupted messages. Imagine that the third group of failing nodes is still communicating with each of the functional groups, but it sends different information to those two groups. Under those circumstances the failing group along with one group of functional nodes can reach consensus, because we assumed two groups can reach consensus without the third. But at the same time the failing group can reach consensus on a different result with the other group of functional nodes.

In the above partitioning into three groups, we could have t nodes in each group, in which case it is proven that with t failures among 3t nodes we cannot reach consensus. Additionally there exist solutions that will reach consensus with t failures among 3t+1 nodes. They are randomized which means runtime is theoretically unbounded, but the probability that the protocol will take forever is zero. On average it completes quickly. For example the Asynchronous Binary Byzantine Agreement protocol operates in round and has 50% probability of finishing in a given round. If it fails to complete it will run another round and have 50% chance of finishing there. The idea in that protocol is that if there are two candidate results to agree on with roughly the same number of nodes supporting each result, they flip a coin, and try to agree on using the result of the coin flip. Trying to agree on the coin flip can only fail if the coin suggested a result that was behind in the number of nodes supporting it. Hence there is at least 50% chance the coin will land on a side, that leads to agreement.

The byzantine failure model is a bit extreme, but that means protocols designed to work in that model are resilient to extreme failures. The stop dead model on the other hand is a bit unrealistic. Which means protocols designed to work in that model are only proven correct under unrealistic assumptions. They may work in practice most of the time. But the proof of correctness isn't valid in the real world. I don't know if anybody have managed to come up with a sensible model, which lies somewhere between those two.

Re:So what did it do all that time?

[kasperd]

All the expensive duplicated hardware in the world won't save you if your clustering software chokes.

I recall a situation where a vendor was trying to sell us an expensive redundant hardware solution. They wanted us to have two replicas of the computer controlling a large machine. But it was deemed too expensive by management on our side. I was actually supportive of that decision for multiple reasons.

• The hardware component they wanted to replicate was the most reliable component in the system. It was the only one we had never had a failure on.
• The entire computer could easily be replaced with a cold spare with no risk of data loss. The new computer could get up to date data in a few minutes by pulling it from the machine it was controlling.
• It wasn't an interactive system with users expecting an answer in seconds. A couple of hours of downtime would go unnoticed by the users.
• We already knew the vendor's software had problems keeping data consistent with only a single replica. So how could I trust that they could get a much more complicated solution right?
• Finally any real consensus protocol belonged to a much higher layer in the stack than the software running on this computer.

Re:So what did it do all that time?

[hawkinspeter]

)

Had to close it, you know.

Re:So what did it do all that time?

[tubs]

> If you want to guarantee a system keeps operating and maintains data integrity when a single computer fails, you need at least another three computers that are still running with no failures. There is a mathematical proof for this.

Can you find this mathematical proof? It'd be most useful.

Re:So what did it do all that time?

[kasperd]

Can you find this mathematical proof?

See http://slashdot.org/comments.pl?sid=3547941&cid=43180375

Re:So what did it do all that time?

[jimicus]

It's even harder in real-world scenarios because more often than not, "We absolutely, categorically cannot afford a failure of any description! We'll spend whatever we need to in order to guarantee this!" rapidly becomes "Maybe we don't need it that badly...." once the costs are presented to management.

Re:So what did it do all that time?

[jellomizer]

Is uptime important? Yes.
Not that years of uptime is needed. But it means how much your fail over should be. If you have a less reliable system (Hardware+Software) then you may need 2 or 3 equally specked systems for a hot fail over. If your system is very solid you can get away with a lower spec system for the fail over. So in case of a problem or maintenance you just have a bit of slower performance (During a slow period) while the other system gets patched.

Besides not all functions are so mission critical that you really need fail over however you do want reliable up-time.

Re:So what did it do all that time?

[kasperd]

Have you ever heard the words "good enough"?

Of course I have. That's exactly what the last paragraph of my comment was about.

With relatively simple replication techniques you can ensure that your service is running mostly trouble free with minimal operator intervention.

Simple replication techniques can work great if your service is mostly stateless. If your service is stateful then a too simplistic replication causes more problems than it solves. That's why in some cases "good enough" means no replication (except from a regular backup).

Re:So what did it do all that time?

[jpvlsmv]

Yup. And running a full marathon is pointless and irrelevant - any one could run 26.2 miles on a couple of months, half a mile at a time.

Besides, if it's that far, you might as well drive.

Re:So what did it do all that time?

[tedgyz]

I have real world proof that fail-overs almost never work. We have a clustered oracle database with expensive hardware and software for supposed seamless failover. In 10+ years I have never seen it actually work as designed. Likewise, we have redundant load-balancers. The backup was unknowingly dead, so when the primary failed we were dead. We had to find a spare device in the junk pile.

Bottom line: Cold spares are a cheaper and more reliable alternative than these expensive hot failover solutions.

Re:So what did it do all that time?

[bigdaddyphil]

What did you do before retirement, Gene? No details needed, just curious.

Re:So what did it do all that time?

[ebvwfbw]

i agree... if you're responsible for a single server performing a mission critical function with no fail over, you may as well just fire yourself

Depends. If you're a Government worker you'll get an award anyway. I've seen that happen.

For the rest of us - No guts no glory!

Re:So what did it do all that time?

[Lord Kano]

I had problems at a place where the bosses' boss was the owner and the bosses were her sons.

It was the most miserable year of my career. As soon as I found another job, I put in my notice and got the fuck out of there.

LK

Re:So what did it do all that time?

[kasperd]

Take the simple task of serving documents over HTTP

True. If your service is stateless, it becomes much simpler. The complexity I was referring to applies to stateful services.

Re:So what did it do all that time?

[InPursuitOfTruth]

Would a Windows 3.1 machine with 3737 days uptime do the trick?

Re:So what did it do all that time?

[Gunstick]

I'm not sure what you mean by failover. For me failover is active-passive. So one node just sits there and starts the applicaiton when the other node fails.
If it's some sort of always-live where the data needs to be replicated realtime to all nodes, I confirm that the complexitiy is not worth the gain in uptime. Such constructions often experience more downtime because of the complexity, not because of the failures they should protect against.

Re:So what did it do all that time?

[kasperd]

I'm not sure what you mean by failover. For me failover is active-passive. So one node just sits there and starts the applicaiton when the other node fails.

How about data users are putting into the system? They expect that if they have put data into the system it isn't suddenly lost. So when the primary dies, the secondary must have all the data. But that means you cannot put any new data on the primary unless the secondary is ready to receive it. And how about the situation where communication between the two replicas fail and they declare each other to be dead?

Oracle sucks.

[RocketRabbit]

I'd just like to leave this here. Yeah, I know Linux is great and everyfink, but Solaris is excellent and better in some ways. Oracle really ground my gears when they stopped supporting OpenSolaris and OpenIndiana is going nowhere fast.

RIP Sun.

Re:Oracle sucks.

[Drinking Bleach]

Oracle never supported OpenIndiana, it's a distribution of illumos (the OpenSolaris fork).

Re:Oracle sucks.

[ebno-10db]

As reliable as Solaris is (was?), it's neither a record breaker nor a first. The old DEC VMS had that sort of reliability, and while I'm personally not as familiar with them, various IBM mainframe OS's are supposed to be/have been even better.

Re:Oracle sucks.

[tnk1]

I don't think his comment suggested anything else. You should probably parse it like this:

(Oracle really ground my gears when they stopped supporting OpenSolaris) && (OpenIndiana is going nowhere fast)

Oracle support only applies to the Left Side of the statement. The point of the statement was to suggest that with support gone, and the only alternative to the supported version going nowhere, the Solaris world is completely Shit Out of Luck.

Re:Oracle sucks.

[Drinking Bleach]

Thanks, you're right. Misread it on account of not being awake for long :)

Re:Oracle sucks.

[unixisc]

I've never really understood why Oracle had to steal RHEL's distro and rebrand it as its own, when they had a perfectly good OS in Solaris which existed not just on SPARCs, but on x86s as well. As for OpenIndiana, I don't get the point of that project since it doesn't support SPARC, and there is a plethora of OSs for x86

Re:Oracle sucks.

[RocketRabbit]

The point of OpenIndiana is ZFS, but FreeBSD actually releases so there's no point to OpenIndiana any more.

For a while people were hoping it'd be a nice community-dirven OS but it turned out that most of the development work was coming from Sun, and while I don't have the whole story it looks like the community fell apart and fractured while trying to get OpenSolaris to compile on GCC.

Re:Oracle sucks.

[interval1066]

hp mpe/ix have excellent uptime records.

Re:Oracle sucks.

[ebno-10db]

VMS isn't a Unix

So I've heard, but I believe it is a "computer operating system". Hence I thought it was a more appropriate comparison than to a bicycle.

and I don't believe you can get ahold of VMS any more

Then into the memory hole!

The IBM mainframes are too expensive

For whom? To operations like banks, for whom downtime is incredibly expensive, they're still worth it. For me, an UltraSPARC like the 280R breaks the piggy bank. I get my x86 hardware from other people's castoffs.

and not open source

As you pointed out, OSS Solaris is toast.

What's your point exactly?

Umm, that some other OS's are/were at least as reliable as Solaris. Was I being that obtuse?

Re:Oracle sucks.

[BitZtream]

What does open source have to do with anything? Uptime only matters if your OS is open source? I don't get it.

Re:Oracle sucks.

[jgarry]

VMS isn't a Unix, and I don't believe you can get ahold of VMS any more. The IBM mainframes are too expensive and not open source, so there's no point in comparing them to Solaris.

What's your point exactly? My point is that Solaris is useful, even in its somewhat dodgy state (thanks Oracle for the paid update program you fucks).

You can still get a hobbyist license: http://www.vmshobbyist.org/faq.php?cat_id=3

Back in the '90s, a VMS magazine pointed out that the posix implementation was good enough to say "VMS is better unix than unix."

Re:Oracle sucks.

[rogueippacket]

I believe this originated from two places; first, the constant stream of FUD from Microsoft that only a commercial OS could provide the uptime required for important applications, and second, the time-honoured tradition of rebooting your Windows boxes as the first step in troubleshooting.

Re:Oracle sucks.

[Anonymous Coward]

When Oracle bought Sun I was working for one of the larger Sun customers. As the deal was being carried out, they promised us nothing was going to change in their relationship with us. But Oracle screwed us over big time. And as they were screwing us over, we were regularly in contact with their sales representatives, who were asking if we were still feeling the pain and assuring us that they were feeling the pain with us.

And to get out of that situation we had to invest in more hardware than we had anticipated. That's when I really learned what vendor-lock-in means. Because we could see only one place to buy that extra hardware from, if it had to work with our existing system. I hope my former colleagues found a way out of that vendor-lock-in.

Re:Oracle sucks.

[Reschekle]

OK, first off, it is not stolen. You cannot steal open source software. Oracle is following the GPL.

Second, Oracle was doing OEL before they acquired Sun.

Solaris is a technically good and high quality OS but its hardware support was limited. If you bought the Sun-branded boxes and Sun-branded cards, you were OK. However if you are white-boxing a server, you had to be careful to select chipsets that were on their compatibility list. Then support got murky at that point even then.

I really, really love Solaris, but let's face the facts. Outside of the SPARC platform, there is no reason for Solaris. Linux does everything as well or nearly as well. Linux is weaker in some areas, but not weak enough to justify the cost and lock-in of Solaris.

Solaris exists for Oracle to milk legacy customers on support contracts who aren't ready or willing to migrate to Linux and commodity x86 hardware . There isn't much if any new development going on, and Oracle is only pushing Solaris to new customers as part of their big data warehouse solutions (where customers have $$$$$ and want to spend it with one vendor) where they want to get people locked in to one vendor.

Re:Oracle sucks.

[DougOtto]

Unbreakable Linux was really just a maintenance contract, not a distro. Sure they added a couple of packages but it was more about a maintenance revenue stream than any sort of innovation.

Re:Oracle sucks.

[RocketRabbit]

Who said that Solaris was the most reliable? I don't believe anybody here did.

Re:Oracle sucks.

[RocketRabbit]

Open source means that when some two-bit operation like Oracle decides to shut down an operating system there is a chance for an organization which relies upon that OS to continue to support it themselves.

If you want to measure uptime in decades, or (in the future) perhaps centuries, open source will probably be the way to achieve it.

Re:Oracle sucks.

[RocketRabbit]

"Even the ZFS utilities are ridiculously complex and entirely inconvenient, and those are relatively recent."

That might be true if you are using a home computer, but if you are looking at managing a large amount of storage, there's nothing even a tenth as useful as ZFS. Everything else is a sort of sick, pathetic time wasting joke of a farce.

Re:Oracle sucks.

[ebno-10db]

An uptime of 3737 days rightly suggests that it's very reliable. I simply thought that it might be worth pointing out that it wasn't a record breaker, especially for the benefit of those who haven't had the opportunity to work with anything other than Windows or various Unix's. Forgive my presumptuousness in pointing it out.

Re:Oracle sucks.

[cmdr_tofu]

Thank you. All Language should have ( ) and && || ||'s. :-D

Re:Oracle sucks.

[unixisc]

The rest of your explanation is fine, but on my first, I used the term 'steal' for a reason. Oracle just took RHEL, and rebranded it - adding nothing. They then ported their applications to that, and then used those applications to get their customers who were using RHEL to either switch to OEL or get substandard support on the installation. How many times have we, on this site, read about people who simply replaced RHEL w/ OEL so that there would be 'only one throat to strangle - Oracle's'.

This - using their presence in one market to unduly influence another - is precisely what the DoJ went after Microsoft for in the 90s. Oracle really didn't do squat to develop OEL - they just did what CentOS did, and rebranded it. RHEL did the heavy lifting of actually developing the whole thing, and Oracle just took the end result, rebranded it and then stole customers from Red Hat. Same as CentOS.

I know that this is open source. But there is a difference b/w what Scientific Linux does, vs what Oracle/CentOS do. Scientific Linux takes RHEL, customizes it and comes up w/ a distro specifically customized for the scientific community. Mint takes Ubuntu, replaces Unity w/ a choice of KDE, LDXE, XFCE and also throws in a new DE of its own - Cinnamon - so that people disgruntled by GNOME3 and Unity can find an alternative (even though Xubuntu, Lubuntu and Kubuntu exist). So there are useful roles there for those who want to roll out their own distros. However, there is little that CentOS or Oracle really bring to the table by rolling out their own distros. Heck, Oracle might even have distinguished itself by putting OEL on SPARC, and offering the solution of customers buying Suns that have a choice of OEL or Solaris, or Xeon/Opteron servers running RHEL. Now that would have been Oracle adding value to the effort.

Re:Oracle sucks.

[mlts]

I will say that AIX is pretty good as well. In general, unless there is a show-stopper patch, or one installs a driver like EMC PowerPath that requires a reboot due to the hooks in the kernel, one can keep AIX up for a long while, only really bothering to update and reboot when the latest tech level is released, and if there are no security specific issues, even that can be ignored, although it is wise to keep up on new firmware stuff just in case.

Re:Oracle sucks.

[tompaulco]

time-honoured tradition of rebooting your Windows boxes as the first step in troubleshooting.

Laws!, how I hate this debugging technique. There are some people that I have worked with who would observe an issue with a program, completely skip reading any of the logging information, and jump straight to rebooting the machine. Fortunately, I try to write my applications to recover gracefully, so when the machine comes back up, the services start up and before long, the application is right back to where it was before, working on the same piece of data and complaining in the log about it.

Re:Oracle sucks.

[Ignacio]

However, there is little that CentOS or Oracle really bring to the table by rolling out their own distros.

CentOS helps keep RHEL "honest" to a certain degree. Could SL have filled that role had CentOS not existed? Possibly, but the customizations made could be seen as an impediment to that.

Re:Oracle sucks.

[SteveFoerster]

I don't think he was disagreeing with any of that, other than that you seem to use "steal" to mean things that it doesn't actually mean.

Re:Oracle sucks.

[Anonymous Coward]

Solaris is a technically good and high quality OS but its hardware support was limited. If you bought the Sun-branded boxes and Sun-branded cards, you were OK. However if you are white-boxing a server, you had to be careful

You almost made a great point that everyone seems to miss... the massive uptimes were a combination of software and hardware. You won't see those uptimes with Solaris on just any old thing... gotta be Sun hardware, and not just any old Sun hardware, but the Sun hardware that was produced before marketing took over at Sun, cheapened the hardwre, and sent the company into... well, you know the rest..

Re:Oracle sucks.

[iggymanz]

some of my clients have those and they all are over ten years old, that architecture had a 30 year run. the last hp e3000 was sold november 2003, and plenty of 3rd party companies will support any model even though hp recently end-of-lifed them

Re:Oracle sucks.

[iggymanz]

Yes VMS, now called OpenVMS, is still maintained and sold as one of the Operating Systems the HP Integrity line and the no longer sold (but still supported) Alpha CPU. The latesest version is 8.4 which came out June 2010.

Re:Oracle sucks.

[stox]

Try running a massively multi-threaded application on Linux. Then tell me that there is no reason for Solaris. We still have a few more years until the fine-grained locking in Linux matches that of Solaris.

Re:Oracle sucks.

[Anonymous Coward]

I've never really understood why Oracle had to steal RHEL's distro and rebrand it as its own, when they had a perfectly good OS in Solaris which existed not just on SPARCs, but on x86s as well.

My understanding was that they were frequently being called in to help diagnose problems that turned out to be Red Hat problems. Rebranding allowed them to collect for support that they were already providing. It also allows them to roll out changes on their own schedule, not Red Hat's. Database servers require few features but tend to be mission critical. As a result, there are few changes that aren't bug fixes that need to be released immediately for a database server OS. They even have the opportunity to do their own QA before releases. Since their servers have a much more limited purpose than those using RHEL, they can do much more effective QA for a given amount of resources.

The real beauty of open source is that this still helps Red Hat. If Oracle finds a bug and fixes it, they will want to patch upstream. Otherwise, they will simply have to reapply the fix with every subsequent release. Those bug fixes make RHEL stronger.

Re:Oracle sucks.

[Brett Buck]

We have VAXes that have been up for at least that long and the only downtimes I can recall since the late 80s were from power failures of those machines not attached to UPSs. And before anybody drones on about "patches", its not connected to the external world.

Re:Oracle sucks.

[JabrTheHut]

Solaris is a technically good and high quality OS but its hardware support was limited. If you bought the Sun-branded boxes and Sun-branded cards, you were OK. However if you are white-boxing a server, you had to be careful to select chipsets that were on their compatibility list. Then support got murky at that point even then.

You sound like you've never had to mediate a 3-way vendor argument between the hardware vendor, the linux support vendor and the HBA vendor, all claiming that it's someone else's fault that the hardware/OS/HBA combo doesn't work, even though they assured you that it did before you bought it. Oh, and you're a top customer, so they want to keep you really really happy. But not "it actually works" kind of happy.

I really, really love Solaris, but let's face the facts. Outside of the SPARC platform, there is no reason for Solaris. Linux does everything as well or nearly as well. Linux is weaker in some areas, but not weak enough to justify the cost and lock-in of Solaris.

Spoken like someone who has never run them side by side in a large estate. Even 10+ years after Linux's enterprise debut, they're not even close. I've just had to reboot 3 RHEL 6 boxes twice each because for some reason they no longer scan the bus correctly. You have to add new disk, reboot, partition, and reboot again. Last time I had to reboot a Sun box because we added new disk was 2004, and that was because the site standards were rubbish and they were configuring their HBAs incorrectly. There's almost no comparison between Linux and Solaris, still, years after all kernel developers started concentrating on making Linux better for the datacentre. The last time I suggested sending a Linux kernel dump to RedHat or SUSE we all laughed. They don't even look at them, they just blame the hardware and suggest we update firmware. Then they cross their fingers and hope. And where's the fabled DTrace equivalent for Linux? I'm sure I missed that announcement, as when Solaris 10 was announced every Linux fanboy said it would be shipped and stable in Linux before Solaris 10 DVDs hit my desk. Fail.

Solaris exists for Oracle to milk legacy customers on support contracts who aren't ready or willing to migrate to Linux and commodity x86 hardware .

Or who want to run large databases with more than a few GB of RAM. Small databases seem fine on Linux, but Oracle or DB2 or Sybase don't seem as stable on Linux as on Solaris when you get up to 32+GB RAM.

There isn't much if any new development going on, and Oracle is only pushing Solaris to new customers as part of their big data warehouse solutions (where customers have $$$$$ and want to spend it with one vendor) where they want to get people locked in to one vendor.

Yes, and it's a crying shame. Oracle are terrible. I know of whole enterprises who jumped ship when Oracle took over. But Linux still isn't there, even though most places I'm working at these days have more Linux than Solaris, HP-UX or AIX, and usually more than all other Unix combined. But there's still too much of the amateur around Linux.

Re:Oracle sucks.

[aix tom]

I always thought they were implemented as "dude" and "man" in English. Something Like:

Oracle really ground my gears when they stopped supporting OpenSolaris, dude, OpenIndiana is going nowhere fast, man.

Re:Oracle sucks.

[Niomosy]

VMS isn't a Unix, and I don't believe you can get ahold of VMS any more. The IBM mainframes are too expensive and not open source, so there's no point in comparing them to Solaris.

What's your point exactly? My point is that Solaris is useful, even in its somewhat dodgy state (thanks Oracle for the paid update program you fucks).

OpenVMS is available. For free if you get a hobbyist license. You can then either run it on Itanium, Alpha (real or emulated), or VAX (real or emulated).

There are several Alpha free emulators out there for Windows. There's also Simh which emulates VAX servers and is available for Linux, WIndows, and probably others.

IBM mainframes may be expensive but when you're talking about mission critical things like core databases for your statement of record at banks, expense becomes a little less significant.

Re:Oracle sucks.

[Reschekle]

You sound like you've never had to mediate a 3-way vendor argument between the hardware vendor, the linux support vendor and the HBA vendor, all claiming that it's someone else's fault that the hardware/OS/HBA combo doesn't work, even though they assured you that it did before you bought it. Oh, and you're a top customer, so they want to keep you really really happy. But not "it actually works" kind of happy.

I was talking about Solaris on Intel. Not sure where you got this from. In fact, you kind of reinforce my point: running Solaris on other people's hardware is just asking for trouble like this, which WAS MY POINT!

Anyway, if you really want to play this game, I'd be more than happy to pull up some of the various support cases I've opened with Sun and Oracle about Solaris and get you to try to explain each one to me, since you're such a bigot for Solaris.

Spoken like someone who has never run them side by side in a large estate

I have and do at my current gig, so shut your pipe. I have also done software development for both. So I know the ins and outs of both OSes pretty damned well. I even admitted to you that Solaris is the better OS, yet you're still not happy with my response. Spoken like a true fanboy you have.

There is one advantage to Solaris and it is the vendor lockin, namely the fact that you have limited hardware combinations, whereas with Intel you have literally hundreds of combinations of chipsets and configurations to support and test against. Again, this is one reason why I do *NOT* recommend Solaris on Intel unless you're buying one of Oracle's own Intel servers where they have actually tested the OS and the hardware together.

Or who want to run large databases with more than a few GB of RAM. Small databases seem fine on Linux, but Oracle or DB2 or Sybase don't seem as stable on Linux as on Solaris when you get up to 32+GB RAM.

I'm running rather large databases, much larger than that, with OEL on Dell branded hardware. It just works for us.

Yes, and it's a crying shame. Oracle are terrible. I know of whole enterprises who jumped ship when Oracle took over. But Linux still isn't there, even though most places I'm working at these days have more Linux than Solaris, HP-UX or AIX, and usually more than all other Unix combined. But there's still too much of the amateur around Linux.

Your only indictment against Linux is that you have some specific hardware issue, that's not really convincing and pretending that Solaris doesn't have those issues is just plain laughable and absurd.

Re:Oracle sucks.

[hawkinspeter]

It's like doctors prescribing antibiotics without finding out what the actual problem is. The thing is that it can fix a huge swathe of problems very quickly, so often it can be a waste of time going through logs when a reboot can resolve the issue.

Re:Oracle sucks.

[Tom]

Actually, last I checked Linux can not show you an uptime of 3737 days.

No, that's not a dig on Linux being unstable. The real reason is both more boring and more interesting at the same time. A Linux system with that kind of uptime would have to be running a kernel from a time where the uptime counter overflows after around 400 days.

And yes, I've seen that happen. :-)

Re:Oracle sucks.

[serialband]

There's openvms http://www.openvms.org/

Re:Oracle sucks.

[iggymanz]

what operating system has Oracle (worth billions of dollars, btw) shut down?

the market shuts down proprietary operating systems; when it's no longer profitable to make one, they aren't made. if you're talking about opensolaris, 1. some parts of it were never open sourced 2. it died from lack of interest and use. 3. the projects that forked the open source part of it can't get enough mind share

Re:Oracle sucks.

[interval1066]

Yeah. I worked for a guy who wrote software to convert data from the proprietary data base those things shipped with to oracle, he was always going on about how sturdy hp3k's were. He's still in business as far as I know, looks like he's expanded his translation support to mssql server, mysql, postgresql, db/2... people still use db/2 huh?? wow.

Re:Oracle sucks.

[AK Marc]

Oracle lost me when people started demanding is as an end, not a capability. "We need Oracle" Why? "Because our competitors have an Oracle."

When you hear something like that, run. I've never seen a company survive when upper management says that.

T'ain't nothin...

[Anonymous Coward]

Last place I worked at still used token ring. Packet-Packet-Give baby!

Last message in system log was . . .

[StefanJ]

. . . Mar 12 11:57:03 hedvig kernel:WILL I DREAM?

Re:Last message in system log was . . .

[cbiltcliffe]

I was thinking:

  Mar 12 11:57:03 hedvig kernel: So long, and thanks for all the bits.......

Re:Last message in system log was . . .

[sysrammer]

We have a winner!

Impressive

[Anonymous Coward]

They should of kept the server online as a way to show off the datacenter infrastructure being able to stay up as well. They could of had the server running an LED display with an uptime clock.

taken down early as a precaution

[Anonymous Coward]

In another 57 years the uptime command might've had rollover issues.

This is news?

[Fished]

I work at a Very Large Company (who must remain nameless.) We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

Re:This is news?

[bobbied]

I work at a Very Large Company (who must remain nameless.) We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

I am not surprised. I've seen Sparc/Solaris boxes run for very long times and even when not properly cared for have run times measured in months and years. I've had to shut down boxes to move them that had been running for 5 years. We where scared to death the disk drives would not spin back up after 2 days in the truck, but when we plugged them back in, they powered right back up. Sun built some SOLID hardware and produced a SOLID operating system.

Re:This is news?

[hondo77]

Verizon.

Re:This is news?

[amicusNYCL]

I work at a Very Large Company (who must remain nameless.) We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

I'm willing to hazard a guess who you work for. Let's see.. you're running servers that have an OS that was released in 1997, and apparently you haven't rebooted them since. Almost like your company is stuck in the mid- to late-90s. You're the only Slashdotter I've seen with an AOL instant messenger screen name in their profile. That can't be a coincidence. You work for AOL. They have you designing the latest Free CD labels.

Re:This is news?

[shafty]

Interesting, I left a Very Large Company in the late 90's after having set up a few Solaris 2.x machines for our R&D projects. I had a Quake server running on one of them. There was a lot of incentive to keep that server up.

Re:This is news?

[Grog6]

Amazingly enough, in my experience, two days in a truck is not nearly as bad as a few weeks in an extremely temperature-controlled, vibration free room.

The drives will weld to the platter if there's no vibration or movement after "spinning themselves flat" over many years' time.

Apparently, all the micro-projections on the surface of the heads and disks get worn off over time, making the disk and heads Extremely flat; they stick like glue when the air barrier between them escapes over time.

Thermal changes and ambient vibration are apparently enough to keep things 'fluid', and not as likely to stick.

YMMV.

Re:This is news?

[jones_supa]

We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

Do they do anything important?

Re:This is news?

[kjs3]

Let me guess...control processors for Erricson or Lucent GPRS or CDMA cell switches? Do I know you?

Re:This is news?

[PhunkySchtuff]

Hard drives haven't parked the heads on the disks for many years now. All hard drives move the heads off the disk surface completely before the platters come to rest, and wait until the platters have spun up before moving the heads back out again.

Granted, we're talking about hard drives from the 90's and possibly earlier (I don't know when they started doing this off-platter parking, but it's been happening for as long as I can remember taking apart hard drives).

I've also heard that the grease that lubricates the central spindle can seize up when the platters haven't been spinning for some time, but since around the year 2000 or so, HDDs moved to fluid dynamic bearings that have no grease in them to seize up...

Re:This is news?

[kjs3]

AOL was running mostly IRIX and HP/UX in that era. No, I didn't work there.

Re:This is news?

[dbIII]

It's well known with bearings and is actually due to stuff from one polished surface diffusing into the other. The smoother the surface the greater the chance of it happening.

Re:This is news?

[kermidge]

I don't remember when they started auto-parking either. Given the expense of these things until recently, one might presume that the auto-park feature was baked in from the very beginning.

I had a 20MB hard drive in '89 that was supposed to autopark, but I always used a small utility program to manually instruct it to park the heads before shut down, just in case.

Re:This is news?

[kqc7011]

Just like a machinist wringing gauge blocks together.

Re:This is news?

[Alioth]

That sounds like something from the BOFH Excuse Calendar.

Re:This is news?

[Squidlips]

You must work for the "gummint" or a gummint contractor...

Re:This is news?

[Sigg3.net]

I've not used any of the Solaris systems. How do they differ from GNU/Linux distros (I.e. what could we learn and port? to Linux?)

Re:This is news?

[bobbied]

Sparc was a processor manufactured by Sun Micro Systems and Solaris was the Unix operating system that ran on that hardware. Towards the end of Sun's life, when Linux was cleaning their clock, they ported Solaris to X86 although the hardware supported was pretty limited. In the end they where purchased by Oracle, which was the seller of the software most likely to be running on a Sun system.

The biggest thing you could learn from Sun is that stability is expensive because it takes lots of dedicated testing to prove your stuff is good. Sun's failure proves that getting reliable systems is cheaper if you go for N+1 redundancy and automated fail over. Not that Sun's clustering solution wasn't useable for applications properly written to support it, it just turned out to be cheaper to write on Linux platforms in the long run.

Uptime fetish

[DNS-and-BIND]

I will never for the life of me understand the "uptime fetish" that uneducated sysadmins have. Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois. The only thing this tells me is that this machine has had an uninterrupted power supply, which is mildly impressive. Otherwise it's a Solaris box which is missing A SHITLOAD OF PATCHES. WTF, sysadmins? What kind of pro sysadmin worships at the altar of individual machine uptime? Much less a Solaris sysadmin?

Re:Uptime fetish

[FileNotFound]

Funny because you're right - "Impressive UPS" is all I thought.

Re:Uptime fetish

[tepples]

Otherwise it's a Solaris box which is missing A SHITLOAD OF PATCHES.

Apply a patch to a service and restart the service, not the whole computer. Or what am I missing?

Re:Uptime fetish

[Anonymous Coward]

Boy, you must be fun at parties.

Re:Uptime fetish

[Richard_at_work]

Impressive if you can do that on the kernel and still be confident of stability.

Re:Uptime fetish

[Cenan]

You can't really patch the kernel while it's running

Re:Uptime fetish

[i kan reed]

He's used to microsoft or apple products?

Re:Uptime fetish

[guruevi]

You can get patches, even kernel patches without having to restart the system. That was one of it's selling points back in the day, some systems even allowed you to hot-swap or hot-upgrade CPU's and memory.

Re:Uptime fetish

[ebno-10db]

I will never for the life of me understand the "uptime fetish" that uneducated sysadmins have. Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois. The only thing this tells me is that this machine has had an uninterrupted power supply, which is mildly impressive. Otherwise it's a Solaris box which is missing A SHITLOAD OF PATCHES. WTF, sysadmins? What kind of pro sysadmin worships at the altar of individual machine uptime? Much less a Solaris sysadmin?

While never patching a box is obviously bad practice, it being able to stay up for over 10 years is a good indication of the reliability of the system. If you were patching from time-to-time, then how long it stayed up without being brought down for any reason other than to patch it would be a useful metric.

Re:Uptime fetish

[guruevi]

And with the right hardware, my OpenSolaris still does it. It "reboots" the kernel but never has to go through the whole BIOS thing. If you ever however have the wrong drivers (like Areca) the system is simply going to complain it can't quiesce the driver and reboot anyway.

Re:Uptime fetish

[jedidiah]

Why would "missing patches" be of concern for a Unix machine?

That sounds like the sort of thing a WinDOS consumer would need to be fixated on, not an "educated sysadmin".

Re:Uptime fetish

[Bigbutt]

The unfortunate software house where the dev teams are broken up after a project is complete. Then approvals are denied to patch systems because there are no devs to correct for any problems that occur due to the patch.

Uptime is all I have.

(FreeBSD box with 3,196 day uptime running internal DNS).

[John]

Re:Uptime fetish

[Anonymous Coward]

If you don't care, you don't understand history. And sadly, looking at your attitude and phrasing, I got a feeling you're older than I and should know it better.

That you understand it's not worthy of worship is a mark in your favor -- but not as big as you're hoping.

It's not fanboyism. It's from the old cult of service. From taking your limited resources on a system that costs more than your pension, and absolutely positively guaranteeing they were available to your userbase.

We didn't all have roundrobin DNS, sharding, clouds in the early 2000's.

Some of us had Sun's, BSD's, Vaxen, and other systems that might be missing security fixes, but that by and large were secure as long as you made sure nobody that didn't belong on it had an account.

Kernel and driver patches? It might be a performance boost, it might be a security patch. It might be a driver problem that could cause data loss, but only if you were running a certain service. A great admin can choose which are needed. A good admin knows they should apply them all

There's something to be said about rebooting machines -- just to make sure they'll still boot. But the best sysadmins didn't need to check -- they knew.

Uptime diferentiated us from our little brothers running windows, who couldn't even change network settings without a reboot. Who had to restart every 28 days or crash horribly. Who could be brought to a grinding halt with a single large ICMP request.

In short, uptime was an additional proxy variable for admin competence (given the presence of an unrooted box).

Yeah, any idiot could leave a system plugged into a UPS in a closet and have it come out OK. But if you didn't get cracked and filled with porn, you were doing something right.

Given elastic clouds, round robin DNS, volume licensing, SAS... it's very nearly cheaper to spin up a new image and run the install scripts than reboot these days.

I'm not convinced this makes modern sysadmin practices better -- just more resilient to single-host failure.

Just the other week we had a million dollar NAS go down for nearly 12 hours (during the week) while applying a kernel update to the cluster.

If you did that in 99 on a Unix system, you'd have probably been shot after the execs showed you out the door.

Somehow, the cult of service availability has been replaced with the cult of 'good enough'

Re:Uptime fetish

[Bacon Bits]

You have no idea if the system can start from a cold boot. And if it fails to start from a cold boot, you have no idea which of the hundreds of patches you've applied in the last 10 years is the one that is causing the boot process to fail, or if it's hardware that's randomly gone sketchy. The last known-good cold state is 10 years ago.

Power systems fail. Backup power is limited. Buildings get damaged and remodeled. For these reasons it is unwise to assume you will never need to power a system off. Even with the super hotswapping of the VAX you would occasionally need to move the system to a different building with new server rooms. If you never demonstrate that a server can safely power back on to a running state, you have no idea what state the system will be in when you do it.

Consider the system in this article for a moment. The last service was removed last year. Why was it left powered on? It was literally doing nothing but counting the seconds until it was shut down today. That's a disgusting waste of power.

Re:Uptime fetish

[ebno-10db]

Maybe that's because *buntu actually gets patched when needed.

Re:Uptime fetish

[arth1]

The old adage holds true: Iffen ain't broke, don't fix it.

If the machine is in an area where security is important, certain security patches might be needed. But that's no certainty. Other patches - well, with an uptime of 10+ years, adding a stability patch which causes downtime seems rather counter-productive.

Then, experienced sysadmins, which you clearly are not, know that like the most dangerous time for an airplane is during takeoff and landing, the most dangerous time for a server is during shutdown and start. Stiction on old drives, minor internal power surges during boot that doesn't affect a running system, and much else can cause problems.

Oh, and there are also services that you may want to provide 24/7 with no downtime at all, so help you cod. You even mention one such in your nickname. But I have strong doubts whether you truly have kept that service up and running 24/7, even with failovers, if you install patches and reboot just to install patches and reboot.

Re:Uptime fetish

[Pecisk]

Rarely you see trollinsh behavior modded insightful, therefore I will bite.

First of all, "linux fanbois" pitched uptime feature 15 - 13 years ago when Windows stability was a joke. And feature wise Linux systems weren't less complex than Windows ones. Microsoft just did quite a number of fundamental mistakes in designing Windows 95/98/98SE/ME line and also older Windows NT versions, having graphical driver in ring 0 in example. All this made Windows usable only with regular reboots. Yes, there was carefully maintained 24/7 Windows systems, but they were rarity.

So while it maybe is obsoleted already (my Windows 7 installation for games resets video driver twice in day), obsession with uptime has some practical merits. Ask any old time Windows administrator.

Another thing is role of the server. There are some systems you really can't switch off even for kernel patches. Such systems are usually designed and configured to keep any security and stability breaches at bay. Also as someone already pointed out, you do patch software, you just don't reboot server, just upgraded services. Also it's usually means you have test system with exactly same hardware and software to test updates on.

Re:Uptime fetish

[h4rr4r]

Why would the box hosting DNS need to stay up?

Mine could stay up that long, but there are a bunch of VMs doing that task so rebooting them is no big deal.

Linux, but no real not to do the same with FreeBSD.

Re:Uptime fetish

[Anonymous Coward]

https://www.ksplice.com/

Re:Uptime fetish

[pipatron]

Actually, the video shows him rooting the box with a custom compiled program as a normal user without entering any password, so it's likely not updated.

Re:Uptime fetish

[jgrahn]

I will never for the life of me understand the "uptime fetish" that uneducated sysadmins have. Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois.

I don't care about uptime per se, but I hate to try to attach to a screen(1) session only to discover it's gone because someone decided it was somehow "good for the machine" to have a power cycle.

I don't ask for years of uptime, just no gratuitous reboots.

Re:Uptime fetish

[Anonymous Coward]

not withstanding the new techniques

So you have never heard of mach I take it... http://en.wikipedia.org/wiki/Mach_%28kernel%29

The idea is everything is a module and good clean (IPC) interface between everything. You can up and down parts of the OS with no rebooting. When a computer reboots in 30 seconds it is not that big of a deal. But back in the 80s it took an non insignificant amount of time to bounce a mainframe computer. So you did not do it if you absolutely did not have to.

Sun OS which is a derivative of BSD had many elements of this sort of thing built in (not 100% though). The closest we came to having a good 'popular' mach like system was NeXT/OSX. Maybe someday we will see Hurd ;)

Linux is a full on monlithic OS with a some bits that are restartable (see modules). See Tanenbaum and Linus raging at each other over it. http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate

Uptime has really started people talking about it at all again. When you want 99.999% uptime you can not even wait the 30 seconds for a restart...

Re:Uptime fetish

[flyingfsck]

The simple fact is that it ran for ten years without needing the patches. I have run Linux web server machines for 4 years with ZERO maintenance. The PSU invariably gives up the ghost after 3 to 4 years. They were never updated and never compromized in all that time.

Re:Uptime fetish

[Anonymous Coward]

The summary is misleading. It was acting as a backup server for it's own replacement.

Re:Uptime fetish

[DNS-and-BIND]

That was bullshit back when I was administering Solaris 2.5.1 boxes, and it's still bullshit today.

Re:Uptime fetish

[bobbied]

It's not like Sun has issued very many Solaris 2.6 patches in the last few years...

Besides... Many Solaris patches simply didn't require a full reboot. In fact, unless you are changing the Kernel, there was no reason to because it just takes longer. Then there is the mission critical system that is on an isolated network that you take a "If it ain't broke, don't fix it" approach. Who cares what patches are on or not? The system just needs to work, day in and out, sans patches.

Windows users amaze me with all the "got to reboot the box" they put up with. Install software? Reboot! Install new drivers? Reboot! Things start to slow down for unknown reasons? Reboot! I simply don't believe that it should be necessary to reboot a box very often. Reboots should not be required unless you are changing hardware and have to actually power it off or need to change parts of the memory resident portions of the operating system (i.e. the booted kernel image). Windows is getting better about this, but you still need to reboot it way too often for all the "recommended" patches to get installed.

Re:Uptime fetish

[tnk1]

I don't know about you, but if I am running a stable version of Solaris, with a version of whatever application that we run on it that is no longer having to be constantly updated, that is pretty much the holy grail of production. While a bazillion hours of uptime doesn't guarantee that is the case, it is a necessary condition for it happening.

As for patches, half the time new code causes as many problems as they fix. And besides, if you're running something like 2.6 or 2.8 on it, you're so far out of support that being behind on your patches at this point is the least of your problems.

Sure, it's a boring job. That's okay, I can fuck around with Linux all I want, with all the extra time I have from not having to babysit rebooting Solaris servers at work.

Re:Uptime fetish

[Impy the Impiuos Imp]

Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois

Are you sure you're bitching at the correct place?

News for nerds. Stuff that matters.

Boy, I'll bet you feel really dumb right now.

Re:Uptime fetish

[Anonymous Coward]

Best be careful, DNS-and-BIND thinks that is bullshit based on his/her early Solaris days.

Our SunOS systems did OK back before then running noncritical stuff so reboots were ok, but the VMS systems and the mainframe stayed up unless there was a damn good reason to take them down, and while there were patches available, none of them were deal breakers like the nearly pretty much monthly critical exploits of modern trade-in-every-three-year OS's.

Yes, pervasive internet access makes a difference (our site was accessible but there just weren't as many internet sewer pickles back then). But the systems (which cost hundreds of thousands to low millions of dollars and supported world-wide operations from two facilities) HAD to stay up and as the previous poster noted it was a big expensive deal if they didn't, so the companies (and the tech folks) went OUT OF THEIR WAY to get systems that were reliable and could be (and were EXPECTED) to stay running as long as power and environmental conditions were maintained. Again, NOT like today except in more limited circumstances.

Re:Uptime fetish

[ducomputergeek]

It was probably left on just in case some legacy remote system was still trying to access that machine for some reason and did not receive the update to switch to new host. It can happen. I know when we switched one of our API's to the new system we left the original API servers up and running for 10 months from the last system call made to that server group. At that point we figured all of our customers had transitioned to updated software. Why 10 months? I think it had something to do with hardware lease was up at that point anyway. The reason we let 3 load balanced servers sit sucking power & money? Because our customers were processing something like $20M worth of transactions a day. An hour of down time translated to $800k, actually it could be a lot more or less because transaction load was not even, of lost business for our clients. It cost a lot less than $800k to keep those servers up for a couple extra months just to make sure that every terminal of every customer was updated.

Re:Uptime fetish

[sjames]

It mattered more before there was commonly available decent server management. While it generally worked fine, it was always a bit tense when all you could do is give the reboot command and start pinging. It would either become responsive in the next 5 minutes and alls well or it wouldn't and you have to take a trip to the data center.

These days for most servers, it's not that big of a deal.

Re:Uptime fetish

[Anonymous Coward]

Had this happen to an NT 3.51 system. Hadn't rebooted it in months. When we finally did "on the way out the door" it never came back.

We restored multiple copies of the OS/Domain Controller going back 6 months. They exhibited the same behavior. Pulled an all-nighter with multiple expensive Microsoft support calls. They had no clue. Eventually it devolved into them telling us to replace individual system files from the original CD. What a joke.

We never recovered the Domain info, even from the Secondary Domain Controller, which we figured would be fine. Everyone had to setup a new U/P in the morning as well as reconfigure all file shares. Luckily it was only lightly used by 50 users or so, and their data was safe, so really just a minor annoyance.

I learned a big lesson that night:

A. schedule maintenance in advance, leaving at least a couple hours for shit like this to be fixed
B. reboot machines when you apply updates
C. don't use Microsoft for business critical tasks because they don't even know how it works
D. The overtime for an 18 hour day is great, but not worth the stress and years taken off my life

Re:Uptime fetish

[Darinbob]

Probably it's due to Windows machines being so unreliable. For awhile there was even the rule of thumb that if software was acting funny that you should reboot. I used to remember that often when I'd see that sort of advice someone would post their uptimes, to enforce the idea that sometimes operating systems don't have to be so crappy,

There's also the idea that you can patch the OS on the fly and keep it running without rebooting. For a time it was sort of considered a silly trick to upgrade your system while it was still running, when it was clearly easier to just reboot and do it from single user. But over time it's turned out to be highly practical since you don't have to preschedule downtime.

But there is the issue of what happens if it won't boot back up after a power failure or hardware failure? Some of those patches might not be quite right. There's probably a backup server anyway (if it's important enough to keep it up this long, then it's important enough to have a failover).

Re:Uptime fetish

[Darinbob]

That is tricky. I remember back in school that they were reluctant to reboot. Someone was _always_ using the computer. Even in the middle of the night there might be some long running job in the background. So when there was a kernel patch that was necessary the downtime was scheduled well in advance. Sometimes though you could in some limited cases patch the kernel on the fly (simple stuff like tweaking constants).

In the Cray supercomputers, they would snapshot the memory images of processes when swapping. This allowed the computer to be shut down for maintenance and then when it came back up all the jobs would continue as if nothing had happened. So you could have some jobs running for weeks or even years.

Re:Uptime fetish

[isorox]

It was probably left on just in case some legacy remote system was still trying to access that machine for some reason and did not receive the update to switch to new host. It can happen. I know when we switched one of our API's to the new system we left the original API servers up and running for 10 months from the last system call made to that server group. At that point we figured all of our customers had transitioned to updated software. Why 10 months? I think it had something to do with hardware lease was up at that point anyway. The reason we let 3 load balanced servers sit sucking power & money? Because our customers were processing something like $20M worth of transactions a day. An hour of down time translated to $800k, actually it could be a lot more or less because transaction load was not even, of lost business for our clients. It cost a lot less than $800k to keep those servers up for a couple extra months just to make sure that every terminal of every customer was updated.

Network sniffer, make sure nothing except the monitoring is talking to the box for 5 weeks.

Re:Uptime fetish

[Anarchduke]

I will answer that one for you. It wasn't the admins who had uptime fetishes. It was heads of various business departments. To their mind a single minute of downtime was completely unacceptable, no matter the reason. I remember a sign in one NOC I worked in that stated something, "Each hour of downtime costs $500,000" or whatever bullshit the number actually was. The CIO had on his IT mission statement, "guarantee 99.9% uptime".

So in essence, admins value up-time because downtime = an avalanche of shit all the way down from the CIO who doesn't care why there is downtime, only that he'll have to explain to the CEO over golf that there was downtime.

Re:Uptime fetish

[Anonymous Coward]

Quarterly, 6-monthly and yearly transactions / reports do happen.

Re:Uptime fetish

[DougOtto]

Not in the same sense. Solaris was a dynamic kernel. Most "kernel patching" was done at the module level. Modules could be unloaded, patched and reloaded without taking the box down. Most of the time, that worked.

Re:Uptime fetish

[arth1]

Consider the system in this article for a moment. The last service was removed last year. Why was it left powered on? It was literally doing nothing but counting the seconds until it was shut down today. That's a disgusting waste of power.

The same could be said about my grandmother.
The answer is that we don't always act rationally, which is probably a Good Thing. We have music, arts, take care of people and things that don't contribute to much apart from our own feelings. Much like having windows so you can look outside costs money in electricity and doesn't contribute anything, it's still a positive thing. If keeping this server alive kept a couple of old guys happy, it could also be a plus for the business, much like the view from the CFOs office.

Re:Uptime fetish

[xororand]

Impressive if you can do that on the kernel and still be confident of stability.

You can actually do that with Oracle Ksplice for Linux.

Re:Uptime fetish

[DerekLyons]

Then, experienced sysadmins, which you clearly are not, know that like the most dangerous time for an airplane is during takeoff and landing, the most dangerous time for a server is during shutdown and start. Stiction on old drives, minor internal power surges during boot that doesn't affect a running system, and much else can cause problems.

On the other hand, I worked on a system for the US Navy that controlled Trident-I missiles... we rebooted both of our main computers every six hours to ensure that we could reboot them when needed - and the first one after midnight included an extensive hard drive self test to make sure it was working to spec. The gentleman down thread has it right, the answer to 100% uptime is redundancy and failover or switchover, not relying on nothing ever going wrong.
 
In addition, you seem to be unclear on the difference between a reboot and power cycling... In the latter case, if you're worried about stiction and power surges, that's an indication that you should have been thinking about replacing the machine for quite a while rather than hoping nothing ever goes wrong. Because eventually, something will - and when that happens, now you've potentially got two problems... the one that brought the machine to it's knees, *and* the undiscovered ones because you've never rebooted or cycled power.

Re:Uptime fetish

[Chewbacon]

Hahaha I was thinking the same thing. I administer a small office server and you bet your ass I update it and reboot it for updates. I do like seeing a long uptime (windows machines can't touch) but that uptime wouldn't mean anything if the machine was compromised.

Re:Uptime fetish

[tlambert]

Funny because you're right - "Impressive UPS" is all I thought.

Personally I was thinking "Impressive MTBF for the disks, RAM, and CPU, too bad no one builds Intel hardware or IDE disks that can do that".

Re:Uptime fetish

[Trogre]

Although servers usually have dual power supplies, so if one power source (eg a UPS) dies it can be replaced without server downtime.

Impressive PSU backplane, perhaps?

Re:Uptime fetish

[Score Whore]

You're very confused. SunOS through versions 4 were based on BSD which was not based on Mach at all. SunOS 5 (aka Solaris 2.x+, aka Solaris 7, Solaris 8, etc.) are based on AT&T Sys-V. Also not Mach based.

Re:Uptime fetish

[arth1]

if you're worried about stiction and power surges, that's an indication that you should have been thinking about replacing the machine for quite a while rather than hoping nothing ever goes wrong

More likely, someone should have thought of that long before the hardware became legacy. When a new sysadmin comes aboard, the best that can be done for legacy systems is often to keep spares and backups, and try not to trigger any faults. The software might not be supported, and the cost of porting can run to millions.

You're lucky if you've never had to support legacy systems. And a company that has them is lucky if they don't get a new sysadmin who first thing causes downtime by well-meaning patching that isn't needed.

Re:Uptime fetish

[cusco]

If you can run things on a private network (so that security patches aren't necessary) Windows doesn't need reboots with any regularity at all. I have a network video recorder at one client's site that I'm quite sure hasn't been rebooted in three years (haven't been to that office in over a year, but the customer makes a point of telling us when he does something).

Re:Uptime fetish

[dbIII]

It's just a way of sticking a tongue out at people that work with desktop machines and think something is rock solid stable if a computer is running all week.
In a lot of places uptime on internal servers is equal to the time since the last electrical work or electrical safety test was done.

Re:Uptime fetish

[DigiShaman]

Capacitors. Because the electrolytics do dry out over time and thus drift out of spec. This leads to all sorts of components including the ICs malfunctioning.

Re:Uptime fetish

[DigiShaman]

It's not tricky at all. This is a failure of communication, not a technical issue. The proper way of scheduling reboots is to let management know there will be scheduled downtime for security reasons (applying security updates and maintenance). Let them know days or weeks in advanced followed by another notification 24 hours later as a friendly (but unwavering stern authority) that the servers WILL be rebooted regardless. For those that lost data, sorry. One person should not hold up the entire company. If said person out ranks you, have a frank and reasonable discussion with them as to why this is an important task. Oddly enough, your job becomes easier if the servers are Windows based. That's because you know update Tuesday will require reboots once a month. Schedule accordingly and with consistency and the rest of the employees will accept this behavior as "normal" and thus expected.

Re:Uptime fetish

[overlordofmu]

You again!!! I thought it was past your bedtime. TIMMY, GO TO BED!!!

Re:Uptime fetish

[garyebickford]

It's partly a cultural thing. back in the early 1990s I built and sold network fax servers. At that time the computers were run by the IT folks, and the telephone systems were run by the facilities folks. The IT folks usually thought nothing of sending out an announcement that "the servers will be down for an hour to install a new toy we just bought, so we can try out the new hotness". Asking the facilities folks to cycle the power on the telephone system elicited looks of horror and dismay.

Which reminds me - Erickson telephone switches used to be running Erlang, which can run hundreds of thousands of threads and can have the entire 'OS' (an Erlang instance or instances in the case of multiple processors) replaced without rebooting. I suspect that there are phone switches out there that haven't been rebooted in 10 or 20 years.

Re:Uptime fetish

[garyebickford]

Back in 1978 I worked with a Perkin Elmer machine that used the last 170 milliseconds of power in the capacitors to save the system state to disk. So you could literally pull the plug from the wall, plug it back in, and the machine would pick up where it left off. Of course this was easier with a non-networked, 16 bit, 16K word RAM machine with a single-processing OS ...

Re:Uptime fetish

[wkcole]

Theoretically "most" but far from "all" for Solaris 9, and no one with production Solaris 9 boxes works that way. The patchadd of Solaris 9 vintage, its dominatrix install_cluster, and the normal pre/post scripts in Sun's patches assume that you are patching in singleuser and don't need such arcana as modunload/modload and rem_drv/add_drv. It might have been possible in principle to pick apart most of the patches from Sun's "Security & Recommended" cluster marked "REBOOT AFTER" or "REBOOT IMMEDIATELY" and devise a method to apply each one without a reboot, but since I'm certain that the core kernel images (for the 280R: /kernel/genunix and /platform/sun4u/kernel/sparcv9/unix) were changed multiple times for Solaris 9 2003-2008 (when last I worked with a few score such machines), it is not possible for any amount of artisanal recrafting of patches and their mechanism of application to have kept this machine or any similar machine both patched and running for a decade.

Re:Uptime fetish

[dbIII]

Iran had some MS machines in a private network that didn't get patched as well. You may have heard about it in the news. It probably only took one person with a USB stick and their centrifuges were toast.

Re:Uptime fetish

[CAIMLAS]

I pride myself in having vehicles which run well, are well maintained, and don't have all the common irritating 'broken' things, which commonly happen as vehicles get used - handles break, doors don't seal right, nobs come off, etc.

I also have a beater Chevy truck that just keeps going and going. I pour liquids into it: some of them burn when they should, some of them burn when they shouldn't, and ultimately, most of them make it either into the air or onto the ground. I'm proud of this vehicle, too, because it's a sturdy, solid, and reliable beast.

Re:Uptime fetish

[modrobert]

You don't need to reboot when applying patches in SunOS.

Re:Uptime fetish

[TheHonch]

Reminds me of when I had to move a Frogger arcade game without turning it of.

Re:Uptime fetish

[Richard_at_work]

I know about such projects, but I wouldn't be confident of stability after using them.

Re:Uptime fetish

[Celarent Darii]

Hope you aren't running BIND without patches, or that you have a good firewall keeping it off the net.

Re:Uptime fetish

[thogard]

There have been 2 patches that we needed to apply to our Solaris 9 servers in the past 5 or so years because we run so few of the SUNW packages. Both of them could be done without reboots. There is another patch that requires unloading the routing system and reload it or a reboot but that patch fixes a timing attack that simply can't be done on our network. If you buy the right support, the last Solaris 9 patches were released about a month ago.

Re:Uptime fetish

[AK Marc]

Haven't you ever rolled over a cart, plugged one power supply in a UPS on the cart, unplug the other power supply from mains and plugging it on a separate UPS on the cart, roll it somewhere new, then transfer it back to rack socket there?

Re:Uptime fetish

[AK Marc]

Seasonal businesses that open from June to September aren't too uncommon. In fact, there are a number of hotels in tourist areas in Alaska that work for less than half a year, making a years worth of profit in that time. They'll be down for months at a time with no transactions. Though they also expect some of those issues and have re-commissioning processes in the spring to take care of such issues, but they might only find out when they run a test charge and have it fail. But they do so with buffer time to allow for changes. Powering up every device, running A/C on full when it's below freezing, and testing all the services they can.

Re:Uptime fetish

[AK Marc]

Many have been fearful to reboot, because "last time, it broke everything!".

It's amazing how many times a stealth update breaks things, but that isn't discovered until a reboot. Or hardware failures that are "discovered" on reboot because the system is happy to run with a corrupt OS partition, once it's loaded to RAM to run.

Re:Uptime fetish

[AK Marc]

These days, rebooting a server OS is different from rebooting the server, as the server is a VM. And so many datacenters have remote IP KVM so you get BIOS screen and such remotely on reboot. If it's not coming back, you know why and what to do about it. And you can even cycle the power on it remotely. Remote everything has gotten better, especially when working with things that have reduced connectivity (remote datacenters and such).

Re:Uptime fetish

[AK Marc]

I worked many late nights on breaking things that didn't count against downtime. If you send out a weeks notice and do it in the maintenance window, it doesn't hurt the 99.9%. The issue is that night shift for daily maintenance isn't practical, so "maintenance window" often 12 hours of work to do in 4 hours once a month.

Re:Uptime fetish

[Bacon Bits]

No, that would be stupid. I schedule a maintenance window, shut the system down, move the system, and then power it back up. Power isn't the only thing our systems need. They're useless without a network, and most of them have fiber attached or IP attached disks back on the SAN. Its ridiculously impractical to move a server powered on while rotating the network and disk controller connections to keep the failsafes alive. And that's to say nothing of how dangerous it is to jar around a spinning hard drive, plus sometimes we're moving the server between the main site and the DR site 10 miles away.

Errr?

[Slartibartfast]

I'm not sure how uptime and Token Ring really compare. Though I will say that I haven't worked on *any* Token Ring since '94 -- and that was a Thomas Conrad bastardization that did 100 Mbit over fiber. Haven't touched the copper stuff since '92.

Better than I've got.

[jtownatpunk.net]

Router's at "Time: 14:08:44 up 335 days, 13:29, load average: 037,0.11,0.02". That's the best I've got. Longest running computer is "1:46pm up 280 days, 21:01, 3 users, load average: 0.00, 0.01, 0.00". Tho it is a roughly 15 year old machine and it's had longer runs that the current run, I doubt it's broken a thousand days straight. But 335 and 280 days is pretty good for equipment that's not plugged into a UPS.

Re:Wow!

[black3d]

Really? Comparing it to Windows 95? You know that was almost 20 years ago, right? It'd getting kinda old. A more apt comparison (considering Solaris 9's x86 release) would be "WoW! That is 2940 days more than Windows Server 20003 could stay up!" ;)

Re: RIP Sun

[DougOtto]

Amen. Made a pretty good career out of Sun/Solaris. Now I spend my time dealing stupid Windows problems.

3737 days in years

[Anonymous Coward]

https://www.google.com/search?q=3737+days+in+years

Re:3737 days in years

[hcs_$reboot]

Thanks, not so many people know that there are 3650 days in 10 years, especially the geeks here on /.

Re:3737 days in years

[stepdown]

Nice try, it's either 3652 or 3653 days with leap years.

Here's the real question...

[jayhawk88]

Did they power it back up again after shutting it off? Just to see?

Re:Here's the real question...

[guttentag]

No, Facebook bought it, hollowed it out and is planning to use it for additional office space, like they did with Sun's old Menlo Park space.

Surprised no one posted this yet

[yakatz]

http://xkcd.com/686/

Re:Surprised no one posted this yet

[jupiterssj4]

Or this uptime-related one http://xkcd.com/705/

Re:Oh yeah? I once had a

[FaxeTheCat]

We actually had a reasonably busy Windows 2000 mail server with Post.Office up for approx 250 days. No big deal really as Post.Office apparently was a well behaved application. As far as i remember we had to take it down due to server room power maintenance. That was before all the network worms hit so that we had to start patching it... which ended the fun...

Netware 3.12

[slaker]

One of my clients had a Netware 3.12 machine on site that operated continuously about about 16 years. It was retired unceremoniously when they moved to a new location, but that machine did not in all its life have a hardware fault or abend.

Re:in other news ...

[crutchy]

i think the real problem was that he couldn't get his concrete slab to compile on his "solaris boxen"... maybe there were too many infinite loops of rebar

Kudos.

[Slartibartfast]

I used to name my boxen "hal", "sal", and so forth.

Re:Kudos.

[Grog6]

hal is too far back; I'm naming all my stuff after Borg; the main server is Unimatrix_Zero. :)

Re:in other news ...

[ebno-10db]

a slab of concrete has been found with an uptime of 3737 years

You exaggerate. The oldest concrete structure I know of is the dome of the Pantheon, and that's only been around for 1887 years. Time will tell if it was well built.

Re: RIP Sun

[h4rr4r]

Should have switched to Linux instead.

Actually no, that would mean less work for me.

a terrible disturbance the /src

[Thud457]

Netcraft confirms Bill Joy just felt a chill like someone walked on his grave.



hey, that's three jokes there, take your pick.

Not a good thing!!!!

[onyxruby]

Last place I was at that had server admins that bragged about /years/ of uptime quickly turned into a discovery that we had thousands of servers that had not been patched in years. Only a few systems can patch the kernel without rebooting and those are the exception, not the rule. It turned into a six month project but in the end we were patching systems that were vulnerable to 5 year old exploits (mix of *nix and Windows).

I had to make the argument that server uptime meant jack, and to make it I put forward the argument that the only thing that mattered was /service/ uptime. Frankly it is the service that needs to be always available, not the server. This is why you have maintenance windows, for the explicit purpose of allowing a given system to patched and rebooted at a predictable time without interrupting services.

If your server is really that important it will have a fail over server for redundancy (SQL cluster, whatever). If your server isn't important enough to have a failover server for service redundancy that it isn't so important that you can't have a maintenance window. Think service, not server!

The only thing that matters is service availability.

Re:Not a good thing!!!!

[Malenx]

Curious why he was down-rated, perceived sarcasm?

Re:Not a good thing!!!!

[iggymanz]

depends on situation. I've worked on client systems that are not internet connected and only are for data entry. most patches serve no purpose in such an environment - no web serving, no email, no file sharing, no command line: the data entry people can't break out of their application.

Re:Not a good thing!!!!

[bobbied]

Only a few systems can patch the kernel without rebooting and those are the exception, not the rule.

You sir, must be a windows admin... Server up-time DOES mean a lot when you have an SLA that specifies 99.999%. Rebooting complex systems of servers just to apply patches simply doesn't fit in the allowed down time. Your mileage apparently varies, and obviously your up-time requirements are lower.

Windows services have grave difficulty with "five nines", heck X86 hardware has problems meeting that. You have to reboot once a quarter or more just to install the required patches on Windows and that will drive you under five nines.. Put a windows box on the internet and you had better keep pace with the patches or else. Not so with Sparc/Solaris. Solaris/Sparc hardware could easily meet 99.999% with limited amounts of fuss and patching was usually not an issue with these systems. Solaris was SOLID, the hardware was SOLID, these systems just run and if you set them up correctly they where safe enough to run unpatched when necessary.

Re:Not a good thing!!!!

[cusco]

I have Windows security camera recorders running on private networks with years of uptime. I'm pretty sure that one is over 3 years now, and some others have less than that only because a wind storm took out power for longer than the UPS could keep them going.

Re:Not a good thing!!!!

[onyxruby]

Windows has nothing to do with patch management and in the example I gave over 90% of the servers were *nix. Every OS has issues that need to be routinely patched, Unix, Linux, Mac OS, Windows. The idea that Solaris does/did not have to patched though is absurd, and Sun/Oracle has released regular patches for Solaris from the beginning.

Let's start with that SLA, it is a Service Level Agreement, not a server level agreement. In any typical SLA you have an agreement to ensure that a given service is up 99.999% of the time, not the server. Even allowing for 99.999% uptime you still have time to perform the occasional reboot for your patch requirements.

Your argument sounds just like the arguments I encountered for allowing servers to go years at a time without being patched and it falls flat. If you have a 99.999% uptime requirement than you have the justification for failover servers that can keep your service up and running without affecting your SLA. Even if you can't get additional hardware you should be able to at least set up a VM for an interim basis to allow you to keep things up and running.

Keeping a server up for the sake of a meaningless statistic at the expense of security is shoddy administration and a practice that needs to die out. The only thing un-patched system does is provide an attacker an opportunity own your box.

Re:Not a good thing!!!!

[evilviper]

Server up-time DOES mean a lot when you have an SLA that specifies 99.999%. Rebooting complex systems of servers just to apply patches simply doesn't fit in the allowed down time.

An SLA contract includes maintenance windows (commonly at 3AM) which do NOT count against you. As long as you do your patching within that maintenance window, you're still at 99.999%.

If that's not the case, then you should have a cluster of servers, at least two, so you can patch and reboot one while the other handles the load, and then failover and patch the other.

Re:Not a good thing!!!!

[evilviper]

Only a few systems can patch the kernel without rebooting and those are the exception, not the rule.

So it's entirely possible that their server was plenty secure.

Kernel patches are usually for reliability improvements, not security, so if you're stable, you don't need most of them.

And the overwhelming majority of kernel security issues can only be exploited by a local user, so if you don't have any local users, and are confident they won't find a way to break-in via your services, you can safely forego them (but "Don't try this at home, kids!") The list of remote kernel exploits is fleetingly small, and it could possibly be that Solaris 9 hasn't had any that were practically exploitable any time in the past decade.

It shouldn't even need to be argued that service uptime is the most important part. Server uptime of this magnitude is just silly bragging rights, which can be accomplished easily enough by not running any useful services on the server.

However, it grew out of a useful metric... Knowing your system will keep running for a couple years, means you can safely schedule your maintenance whenever is most convenient for you, without concerns of needing to schedule a last-minute reboot to address some misbehavior. I know I used to work with old systems where the accepted procedure was to reboot them at a set time every week, because keeping them running much longer than that would most likely mean some intermittent misbehavior. You can find stories all the time of some critical system failing, because it's known to need to be rebooted once a month, or similar. It even happens with air-traffic control systems, and somehow, people find this horrible restriction to be perfectly reasonable and acceptable... right up until Bob the Janitor forgets to reset it one night.

In addition, the stability of a given system lets you get away with fewer servers. If your cluster of servers are so unstable that there's a chance half of them will crash in a given night, then you need 100% redundancy. Meanwhile, if a crash is extremely rare, then n+1 is fine, and much, much cheaper.

Re:Not a good thing!!!!

[bobbied]

Having 3AM maintenance windows is *not* an option for some applications. We did have redundancy in hardware but as it turns out, the application I was fielding was one of those that couldn't stand downtime so even scheduling in advance didn't get me off the hook for 99.999. It helped keep the customer happy to tell them we where patching for reliability and do it at times the transaction rates where lowest, but we still had to count the down time. This pretty much made it so we didn't patch unless we knew the patch set actually fixed something we needed fixed.

Re:in other news ...

[bobbied]

>

maybe the sysadmins liked them but as a developer i hated solaris boxen. the libraries were always years old, nothing modern would compile, the cli tools were slightly incompatible with linux scripts, ...

They may be a pain to write and deploy programs on but they will run forever once you do...

Fully characterized platforms, take a LOT of testing effort and testing at this level takes lots of time. The Sparc/Solaris platform was behind the state of the art, but it was stable, stable, stable. Solaris on X86 wasn't bad, if your hardware was supported and you didn't really need the GUI to be local, but it wasn't as stable (mainly due to the hardware).

Sun did their stuff right for the most part, but got seriously hurt by Linux (Red Hat in particular) and in the long run couldn't make reliability pay well enough. Who wanted to buy new when the old stuff was still humming without a reboot 5 years later? Not me.

Got to love that sun blue...

Linux on SPARC

[unixisc]

If you are talking about SPARC based equipment, couldn't you have simply installed Linux on them, replacing Solaris? A number of Linux distros had been on Solaris since the beginning - RHEL, Debian, Caldera, et al. That way, you could have used those, and still had your favorite Linux stuff

Re: RIP Sun

[DougOtto]

I do Linux too, but on a consulting basis. Unfortunately it was either take the Windows gig or be unemployed.

Re:Wow!

[asm2750]

So in the grim-darkness of 21st millennium Microsoft Windows still exists?

I'm not impressed...

[bobthesungeek76036]

Take a server and change the date to 10+ years in the past. Then reboot and change the date back to today. Uptime says "3737 days". How do we know this is not smoke and mirrors???

Re:I'm not impressed...

[phantomfive]

Because who cares? You don't win awards for that, you don't even get respect, other than the same kind of respect someone gets for completing a 5000 piece puzzle when they could have just bought an already complete picture. It's just a story, you enjoy it for the story's sake. This guy added his own story.

If you don't enjoy stories about servers, you might not be on the right website.

Re:I'm not impressed...

[jcdr]

This might not work if the kernel use a monotonic clock for the uptime like Linux do:

root@test:~# date -Is && uptime
2013-03-14T22:58:54+0100
  22:58:54 up 5 min, 1 user, load average: 0.30, 0.89, 0.48
root@test:~# date 010100002000
Sat Jan 1 00:00:00 CET 2000
root@jtest:~# date -Is && uptime
2000-01-01T00:00:03+0100
  00:00:03 up 5 min, 1 user, load average: 0.20, 0.82, 0.47

Uptime is still 5 minutes on this test virtual machine, not 13 years.

Re:I'm not impressed...

[Score Whore]

Depends on the version and patch level. Within the last couple of years I've had SPARC boxes that had bad hardware clocks and any power cycle / boot / ntp startup would result in a three thousand day uptime.

Re:in other news ...

[KiloByte]

Incompatibility with linux (I guess you mean GNU) scripts is understandable, incompatibility with basic POSIX requirements is not. If something works both on GNU and BSD systems, there's a fat chance it's a fault of Solaris rather than the script.

(I dislike using the name "GNU/Linux", but here the distinction matters: GNU works on kfreebsd too (ie, BSD kernel, GNU userland), and if one's crazy, even on hurd. And I strongly suspect you didn't mean Android, which uses Linux but doesn't pretend to be UNIXy at all.)

Re: RIP Sun

[h4rr4r]

That sucks.
Well, based on the recruiting calls I get might be about time to start looking again.

Re:in other news ...

[DdJ]

maybe the sysadmins liked them but as a developer i hated solaris boxen. the libraries were always years old, nothing modern would compile, the cli tools were slightly incompatible with linux scripts, ...

Myself, I hate when developers depend on the newest versions of libraries and stuff.

I run Debian on my servers. If your app can't run on top of the older versions of the libraries, then... I just don't need to run your app, at least not for a few years yet. I'll take "stable" over "modern", please.

Truly Impressed

[DaMattster]

That is the stability of UNIX and the advantage of using a mature code base. Try doing THAT with Windows!

Re:Truly Impressed

[iggymanz]

old Unix has a ton of security holes though, wouldn't want a web server right on the internet with it

I've worked on Alpha VMS systems with 15 years uptime.

Re:Truly Impressed

[ebno-10db]

Yay VMS! That was one hell of an OS. It's a shame they didn't open source it before they shut off the lights. And as to the people that think Ken Olsen was a clown for saying that "Unix is snake oil", back in the 1980's when he said it he was largely right. Those old Unix'es sucked in terms of security, reliability, efficiency, standardization (no POSIX, BSD vs. ATT, oh boy!) you name it. They were nothing like the Unix'es we have today, or even 15 years ago. And the idea of any Unix being open source was iffy and conditional at best (maybe in an academic environment).

Alpha was amazing too. First 64 bit uP and the fastest one out there from the day it was introduced. Even after they stopped upgrading it, it took 2-3 years for the competition to catch up. So much for the idea that if you build a better mouse trap the world will beat a path to your door.

Re:Truly Impressed

[iggymanz]

HP calls it OpenVMS now, their big Itanium boxes can run it, and Alpha version still supported till 2016:

http://h71000.www7.hp.com/openvms/openvms_supportchart.html

Re:Truly Impressed

[bobbied]

Security holes? Only if you put them on line without securing them do you have many holes. Unix did come "out of the box" wide open and needed to be configured some to be safe, but they never where cesspools of virus attacks and script kiddie exploit targets like IIS and Windows...

Re:Truly Impressed

[ebno-10db]

I thought it was stone cold dead. Thanks. Guess I'll postpone the memorial service. A shame though that it's slowly dying instead of being a real alternative OS.

Re:Truly Impressed

[ebno-10db]

That depends on what you mean by "old Unix", as the GP called it. Go back far enough (20+ years) and Unix security was atrocious, even by the standards of an era where servers weren't attacked 24/7. What you get today is not your father's Unix.

Re:Truly Impressed

[iggymanz]

not slowly dying if it's sold on multi-million dollar big iron that's used by banks, larger cities, insurance companies, etc. products that are used by places with IT budget in the tens of millions of dollars just aren't always on the radar of popular IT culture. just like the nonStop OS which also runs on the same hardware as OpenVMS, popular with stock exchanges, big cities, banks

Re:Truly Impressed

[bobbied]

Actually, "Old Unix" and "Today's Unix" really differed in the standard security settings. In the old days.... Nobody really cared about security and you got a *nix system with all the standard services running, no firewall and with a default Root password straight out of the install. Now days, this is not generally the case. You are not going to get Telnet, FTP and RPC unless you ask for them and they will likely make you change the root password and setup a firewall during the install process.

I don't think *nix has changed all that much overall, only the default security posture is different.

Solaris was never "supported" in the true sense

[Anonymous Coward]

That's why Opensolaris even existed in the first place. So people couldn't be gouged for documentation, critical security updates, and support. I used Linux a lot before using Solaris for about 4-5 years exclusively as an OS in a couple projects. The main reason for this and I think a lot of people's favorite thing about Solaris is the ZFS filesystem. All the cool stuff it does, it's probably the best filesystem ever made so far and I really like it.

However my happy Solaris experience ended there, this coming from a Slackware user. The packaging system was crappy (had to go to some sunfreeware site to get the most basic things), The default services for Lamp on solaris 10 i think it was did not work properly.. You then had to get this thing called coolstack, which enabled a stable lamp enviornment, which evolved into some "webstack' bastard. That and the damn 'service contract' you needed to get critical security updates. The actually OS updater for critical patches caused a complete system reinstall a few times. This I could never figure out or even question anyone because you needed a 'service contract'. It was just madness. To be honest Sun is/was just as bad a Oracle as far as that shit went - The only difference between sun and oracle is that sun also made amazing hardware that seems to run forever.

So coming full circle, if Linux ever got ZFS or some such badass equivalent filesystem then it would be a perfect world for me. unfortunately I think license restrictions prevent this (though i hear freebsd partially supports ZFS now due to a difference licence)

Re:Solaris was never "supported" in the true sense

[RocketRabbit]

ZFS on Freebsd is stable and up to date. Why fool around with Linux and its flighty change everything on a whim philosophy when you can have a stable Unix that is binary compatible with Linux in the form of FreeBSD?

Re:Solaris was never "supported" in the true sense

[Builder]

Because I can't get the Brother MFC7420 working properly on FreeBSD

Re:Solaris was never "supported" in the true sense

[Celarent Darii]

It works fine in FreeBSD, just don't use the proprietary drivers.

Here is the magic link: http://masterofpc.wordpress.com/2009/11/08/brother-mfc-7420-under-linux-without-the-proprietary-brother-drivers/

Missing services patches vs kernel patches

[erice]

Why would "missing patches" be of concern for a Unix machine?

Missing services patches can leave one vulnerable to being hacked. Fortunately, you don't need a reboot to install those. Security related kernel patches do happen and they do require a reboot. However, these are generally of the privilege escalation variety and require specially written code to exploit. If you don't have untrustworthy people logging in to your machine it isn't a major problem if you don't have all the kernel patches.

Of more serious concern is the general lack of patches for Solaris 9. Solaris 9 patches released from November 1, 2011, will have Vintage/Extended access entitlement by default, which means that only customers with an Extended Support contract for Solaris will be able to access them. Updates to the Recommended Solaris 9 OS Patchset will cease at that time.

Re:Missing services patches vs kernel patches

[jedidiah]

> Missing services patches can leave one vulnerable to being hacked.

The same kinds of practices that make 10 year uptimes for Unix unremarkable also contribute to security being far less problematic even in the absence of constant patching.

Re:in other news ...

[femtobyte]

And that's why concrete is such an awesome building material. In the short term, it might be a lot easier/faster to whip up a structure out of mud, sticks, and goat hide --- mixing, forming, pouring, curing concrete is a real pain. However, the mud-stick-goat solution doesn't work out so great if you need a structure that endures for the ages.

And they shut it down?

[prisoner-of-enigma]

Kevin Flynn was trapped in there!

Re:And they shut it down?

[shoes58]

Yes, thoroughly de-rezed, Im afraid. Pity.

Exploitable?

[tepples]

How often is a kernel bug remotely exploitable if the applications running on the server are obtained from trusted sources and patched often?

Re:Exploitable?

[Richard_at_work]

A kernel bug is only one step away from being remotely exploitable - all it takes is a non-privileged exploit to gain access to the server, and then the local bug is exposed.

conflicted

[binary_slim]

as a testament to the stability and reliability *nix this is awesome... as a support person, it makes me flinch and want to cry.

What better relational query language?

[tepples]

MySQL can die for all I care. SQL likewise. Horrible language.

What language would you prefer to query a relational database?

Re: RIP Sun

[DougOtto]

I'm not. Our Dice overlords installed a "log in with FB" link for creating accounts. Had I known it was going to stick that stupid icon on everything I'd spent the extra 30 seconds typing stuff in.

And there you have it, folks.

[Joshua Fan]

Story of the day: nobody gives a damn about uptime bragging.

Re:in other news ...

[cusco]

I used to work at a place that had AIX, OS2, and NT4 servers, and one frelling Solaris Sparc server. Filthy Sun box froze and needed rebooting (sometimes by pulling the power cord because it was so frozen) more than all the other servers combined. We celebrated its retirement by throwing it off the roof into the swamp.

Re:Oh yeah? I once had a

[cusco]

My NT4 domain controller held the record for uptime in our office in 2000, with 720 days. Then the surge suppressor it was plugged into crapped itself a couple of months after I left that job and toasted the power supply.

Re:in other news ...

[larry bagina]

I read somewhere about a stable solaris machine with a 3737-day uptime. How's your uptime?

Not bad

[ender-]

Best I saw myself was 6.5 years on a Solaris 8 system. I took a screenshot before I shut it down:
http://www.flickr.com/photos/doubletwist/3662948158/

And yes, I know it was insecure. It wasn't a system I managed outside of being tasked with decommissioning it.

Re:in other news ...

[Score Whore]

If you had a problem with POSIX compatibility on Solaris, it's because you don't know Solaris. There are specific paths you should specify for the various POSIX standards, /usr/xpg4, /usr/xpg6, etc. You might try "man -s 5 POSIX" for a start.

yeah... solaris 7 machine here...

[ebunga]

ebunga@rock:~$ uptime
    6:26pm up 3969 day(s), 15:20, 1 user, load average: 0.00, 0.00, 0.01

Yeah, like I'm letting that machine onto the public internet. Long uptimes aren't about reliable operating systems. It's all about reliable power.

Re:in other news ...

[jones_supa]

Additionally, concrete is the most used material by man, by volume.

Grammar minifix

[Anonymous Coward]

You should use "have" in place of "of".

five nines is for the service, not the server

[Chirs]

As long as you've got proper redundancy (which is necessary anyway for five nines) then it's no problem to periodically reboot during a maintenance window to apply reboot-required patches.

In fact, this is a good thing since it ensures that you *can* come back from a cold boot, and it gives you a chance to run offline diagnostics.

Re:five nines is for the service, not the server

[bobbied]

What you say is true, up to a point. 99.999 is going to be really hard to meet if the hardware under the application is not up to the task. N+1 redundancy is helpful, but you still need reliability in the N+1 system or you will pay a price.

Up-time north of 99.9 starts getting really expensive even if you are looking at application availability. Consider automated fail-over processes and things like clustering. The problem becomes increasingly more complicated and solutions become more and more prone to errors as you add hardware to overcome the reliability issues of each system. The classic problem is a data base holding financial data that must always be accurate. When you go check your bank balance, it needs to be the actual balance right now. If there is a chance of it not being correct or a time window for a transaction to post, then you can bet somebody will figure out how to game the system and say withdraw the same money twice from different ATM's. Banks would not stay in business too long if they allowed this or made it where you couldn't hit the ATM at 3:15 AM because the server was being failed over for patches.

Re:in other news ...

[dkf]

maybe the sysadmins liked them but as a developer i hated solaris boxen. the libraries were always years old, nothing modern would compile, the cli tools were slightly incompatible with linux scripts, ...

Solaris was nice by comparison with some of the other commercial Unixes. I saved my hate for IRIX and Ultrix. IRIX's compiler was the nastiest I've ever encountered (and the toolchain was one of the very few that the fancier parts of the auto* toolchain choke on, at least in 64-bit mode) and Ultrix was one of the last bastions of mandatory static linking. Ugh.

By contrast, Solaris was pretty close to Linux; writing code to be cross compatible wasn't hard (provided you avoided a few commands and didn't write endian-sensitive C code).

"boxen"

[gatkinso]

Please never use that term again.

Re:"boxen"

[bobaferret]

I never could make up my mind on the whole "boxen" thing. Some days it was irritating enough to kill over. Other days it would just slip out, like "pop" instead of "coke" from the lips of a southerner forced to live in chicago for too long. At a minimum it does seem to show ones age though...

Re:"boxen"

[sysrammer]

I never could make up my mind on the whole "boxen" thing. Some days it was irritating enough to kill over. Other days it would just slip out, like "pop" instead of "coke" from the lips of a southerner forced to live in chicago for too long.

The germanized plural of "box" is simply a nod to our Northern European professionals. I use it when I'm feelin' a bit deutsche.

At a minimum it does seem to show ones age though...

It's not age, it's seasoning.

Re:in other news ...

[dbIII]

The latest annoyance is finding tar archives that solaris tar can't open. My message for the day on a solaris box, which is now only a tape server, now tells people to use the gnu tar if the solaris tar won't work.
I've still got a pile of solaris 6 machines sitting in the back of trucks because the stupidly expensive control software for the stupidly expensive stuff they are running comes from a place that likes to charge but has been too cheap to hire developers to update it to run on anything new. It's complex enough that vendor support is necessary and they don't support it on anything newer.
I also had a sparcstation10 running SunOS5 up until last year as a print server for an odd vector graphics format, but managed to put a wrapper around the software and get it to go on solaris10. There was a newer version of that software but it fell for the "put everything in a database" fad and they never managed to put all of the useful features in the rewrite (so any text in the images looked like crap).

It says ...

[PPH]

.. to consult a physician if its up for more than 4 hours.

Re:in other news ...

[KiloByte]

/usr/xpg4/something is not /bin/sh, the latter being what POSIX requires.

Re:in other news ...

[Baloo Uriza]

I thought that was Interstate 405 in Portland before ODOT repaved it.

Not surprised

[efalk]

I used to administer a Sparcstation 10 being used as a server in a lab. The only time I ever needed to reboot it was for an OS upgrade or a power failure, and those happened more than a year apart typically.

My /. user number? I'm honored!

[Shag]

I know, I know, it's just a coincidence...

AT&T 3B20D's

[stox]

I don't know this for sure, but I suspect there is one out there with 30 years of uptime now, or damn close to that, running Unix-RTR as part of a 5ESS switch.

Re:in other news ...

[nitehawk214]

a slab of concrete has been found with an uptime of 3737 years

You exaggerate. The oldest concrete structure I know of is the dome of the Pantheon, and that's only been around for 1887 years. Time will tell if it was well built.

That number is pretty close to the uptime of Stonehenge, though.

Re:in other news ...

[garyebickford]

I always thought it was pizza. And beer.

Re:in other news ...

[AthanasiusKircher]

a slab of concrete has been found with an uptime of 3737 years

You exaggerate. The oldest concrete structure I know of is the dome of the Pantheon, and that's only been around for 1887 years. Time will tell if it was well built.

Umm, who cares about what "you know of"? What matters is historical fact. The Colosseum, for example, contains large amounts of concrete and was finished a half-century before the Pantheon. Lots of concrete was used in rebuilding after the great fire in Rome in the mid first century as well. But, of course, Roman concrete was around for centuries before that.

And yet, all of this is irrelevant, since concrete was used in Egypt, Syria, China, and other places thousands of years earlier. There are in fact concrete columns in Egypt that are still standing and have been dated to roughly 3600 years old. There are examples of floors and other smaller structures that have been discovered elsewhere that are much older. Romans perfected the materials and used them on a huge scale, but the basic idea of concrete is much, much older.

Hold a candle for uptimes.org

[kriston]

I used to get excited by long uptimes. People who were obsessed by this concept started this silly web site called uptimes.org. After a while of blatantly fraudulent uptime claims and other silliness it was shut down.

Nobody cares anymore about computers that haven't been turned off for ten years. In my own house I have experienced 400+ days of uptimes, which is an impressive feat, but nobody cares, and the more you think about it, nobody should care.

Yes, nobody should care about long uptimes. The reliability of a system is shown by how perfectly it recovers from a system failure--not on the reliance of a power supply that keeps it from having a system failure. That's a philosophy that has served me and my systems well for more than twenty years.

Still, when I shut down the servers in my house with 400+ day uptimes, I have to shed a tear and a quiet *sniff*. Sigh.

Re:in other news ...

[Celarent Darii]

I don't think Stonehenge can claim that it is operating though. They still don't know what it was used for. The Pantheon on the other hand is still used as a church. It's a very impressive structure - a dome with a hole in the roof. I'm really curious how they pulled off that engineering trick without heavy machinery,

Stonehenge is just a bunch of rocks standing in a field. It's like comparing CPM with a Symbolics Lisp Machine, no comparison.

10 years up, 1 day until copyright removal

[Tom]

If you live in Germany, the video is unavailable. Apparently it contains some music from UMG (or someone claimed it does).

10 years of uptime and one day until the video was killed by the copyright mafia. Way to go, guys!

Re:*nix does not need to reboot for more updates u

[serialband]

Kernel updates generally required reboots even in the unix/linux world. In Windows, you could also avoid a reboot if you stopped the services that are being patched and restart them after a patch was applied.

I still have fond memories of Sunos!

[bob_jordan]

I remember getting a Sunos box past 2 years of uptime and that was used every day as my personal desktop machine in the 90's. Those 19inch mono screens are great for xterms.

I suspect in a few years, there will be quite a few Raspberry Pi computers buried in hardware projects happily ticking over. I know I will be using some of the camera boards for long term time lapse photography so I hope they last a few years without reboots. :-)

Bob.

If it's not broke, don't fix it

[tepples]

Sometime they're about performance, fixing potential bugs, enhancements, additions, etc.

In the case of long-running production services, if it's not broke, don't fix it. These patches should be tested in a test environment before deployment to production, lest a service fail because it was relying on undefined or otherwise unspecified behavior.

Re:in other news ...

[nitehawk214]

I don't think Stonehenge can claim that it is operating though. They still don't know what it was used for. The Pantheon on the other hand is still used as a church. It's a very impressive structure - a dome with a hole in the roof. I'm really curious how they pulled off that engineering trick without heavy machinery,

Stonehenge is just a bunch of rocks standing in a field. It's like comparing CPM with a Symbolics Lisp Machine, no comparison.

It is a pile of rocks, so I would say it isn't operating... but it is quite literally "up".

Confusing reliable with available.

[jotaeleemeese]

A replicated system may be less reliable, but is more available.

That means that in your single computer scenario, if your server goes down, you are toast.

But in a replicated environment although you will have more failures overall, they won't kill the service, since the redundancy will give you a higher degree of certainty that whatever you are running keeps ticking.

These kind of redundancy solutions are normally sold as Highly Available, not highly reliable. The clue is in the name,

I don't set my sights too high!

[Friday10]

Years huh, I can't go a 2 days without a Flash or Java update with a reboot.

Red Hat's defenses

[unixisc]

I'm not an employee or even a user of Red Hat. However, Red Hat does do a number of things that costs money - from hiring Linux developers from all specializations to running their certification programs to providing a corporate face to the OS that is not really provided by the likes of Canonical or Debian. The cost of doing all these things have to be factored into the price of not just their services (for those who do buy them) but also the software itself. As per GPL, Red Hat does have to make its source available, but the GPL is not just ambiguous, but not at all hostile to any organization not providing compiled binaries. Red Hat's brilliance is that they use this to provide something that users can share, but to build it, they'd have to get Red Hat involved. One of the few income protection schemes in a business where the Redistribution clause has pretty much killed the ability to recoup ones costs.

I'm glad that Red Hat has managed to figure out how to foil both Oracle & CentOS. I mean, what exactly does CentOS bring to the table by building something that's binary compatible w/ RHEL? Why not just build their own distro, forked from RHEL at some point, just like SL did? SL has its goal to service scientists and targets scientific needs, and their apps just have to work w/ SL. If people want Red Hat, they should be prepared to fork out the cash to buy the distro, which can then be installed on as many computers as needed. Going to CentOS just b'cos they don't want to pay is another instance of the Linux crowd being reluctant to put its actual money where its mouth is.

CentOS does not do things like Red Hat does, and for them to just take Red Hat's distros and just try compiling & reselling them, while an exercise of GNU liberties, is just diluting Red Hat's income stream. Why not just take one particular version of RHEL, and fork things from there, and make it your own, like Mandrake, SL and others, instead of trying to erode Red Hat's customer base at every version? What Oracle does is even worse. SL does this the right way - they forked Red Hat at some point, but from that point on, concentrated on making their distro the primary OS for the scientific community. I suspect it's even a good platform for people who want to do CAD/CAM, engineering simulations and so on.

Re:in other news ...

[Score Whore]

You say that /bin/sh is what POSIX requires. You do realize that you're going to need to be more specific as there are more than 10 standards under the POSIX umbrella and they are incompatible. So if you're going to make some point about POSIX compatibility, then you're going to have to fine tune your argument significantly beyond a simple "incompatibility with basic POSIX requirements."

Particularly since Solaris is one of the few OSes that even makes an attempt to provide compatibility to multiple versions of the standards.

Beat you seven weeks!

[coganman]

XXX:/ #uptime
9:41am up 3788 day(s), 13:14, 2 users, load average: 0.01, 0.02, 0.02
XXX:/ #uname -a
SunOS XXX 5.6 Generic_105181-30 sun4u sparc SUNW,Ultra-250

This leads to the old joke ...

Q: "What do you call a computer that's never patched, never upgraded, never remediated, never updated, and never brought into normal, current production standards?"

A: "A mission-critical, business-critical production server"

No professionals here, I guess

[whitroth]

I skimmed through a number of comments.

Now, *real* professionals, if it's not already arranged, arrange for this thing called a "regular maintenance window", which everyone up above signs off on, and you get control to do what's necessary, and everyone knows what they're supposed to do to work around it.

And don't talk to me about "mission critical" - this is the way it was done at the 911 Call Center for one of the five biggest cities in the US, 2-3 times a year, when I worked supporting them a dozen years ago. You don't get more "mission critical" than that.

              mark

Re:No professionals here, I guess

[crutchy]

What's mission critical about "the 911 Call Center"? Maybe the US government thinks mass telemarketing to try to convince intelligent folk that the WTC towers "collapsed" is mission critical, but as far as i'm concerned there is nothing more mission critical than the server hosting a web page with a photo of my stretched open ass hole having six sigma availability.

Re:in other news ...

[crutchy]

Stonehenge is just a bunch of rocks standing in a field

that's what the aliens that put them there wanted us to think... stonehenge is really a device for spying on us and transmitting info back to the mother ship... they're coming man!

Re:in other news ...

[crutchy]

If you want to get pedantic, you could possibly argue that there is natural concrete somewhere that is millions of years old (maybe near Mount Vesuvius).

All of this is irrelevant though because TFA article is about a computer, not concrete, but it's still funny how we all seem to enjoy the odd foray into these little tangents on dotslash.

Re:in other news ...

[crutchy]

problem with linux/foss (or any software really, but more pronounced in foss due to decentralization) is that when your package has dependencies on packages maintained by others, you can't always tell what is going to happen to those other packages (unless you're mates with all the maintainers, which would be ideal). if (for example), the maintainers of xorg made a change and it unwittingly broke old functionality (every change carries with it the risk of breaking something; even if you are pedantic about unit testing you con only reduce the risk, not eliminate it altogether, and unit testing won't uncover integration bugs anyway). so in this example, your software may not work with the latest version of xorg until either xorg maintainers fix their bug or you come up with a new release that doesn't use the broken functionality. this could also happen if microsoft broke (or deliberately removed) functionality in one of the windows libraries.

Re:in other news ...

[crutchy]

My message for the day on a solaris boxen

ftfy

Wording and tense minifix

[crutchy]

If you want to get picky...

of "of"

...isn't ideal word choice, and you should have used past tense.

Re:Windows is Better

[crutchy]

I guess Windows 8 is comparable to a "crappy ass" version of any software... fortunately the rest of us don't use "crappy ass Solaris", we use the normal version, which isn't crappy at all.

Re:probably a windows admin

[crutchy]

that's why mission critical servers should be headless with ssh access only

GEMA

[dave87656]

Can you post that on Vimeo so those of us in Germany can watch it? Most videos which have music in them are restricted here but they are stuck on youtube so usually Vimeo will work for a while.

Re:Throw a bomb on GEMA!

[dave87656]

Do these fucking retards think that The World is their property?

In a word ... yes

When you buy a smart phone, they collect something like 40 euros. They make more money on the smart phone than the manufacturer does! And they collect that because you "could" uses it to store and play music. But, if you were actually to do such a thing, which you have now paid for with the 40 euro surcharge, you would be committing a criminal act. And the smart phone is just the tip of the iceberg.

A friend of mine is a musician and plays in clubs. He plays his own music and the club still has to pay GEMA more money than he makes. So, yes, they at least think they own all music. This is my opinion, of course. (My lawyer says I have to write that so they don't sue me).

4 years on linux

[dave87656]

Our linux server was up for four years (exactly actually). I shut it down to upgrade to a more powerful box.

Re:in other news ...

[dbIII]

So the only thing you have to add to that post is an opportunity to squirt out some little bit of leetspeak and pretend it's a correction? Why bother to do something so boring and pointless? A description of your lunch would have been a far more interesting contribution.

Re:in other news ...

[crutchy]

at least my contribution had some degree (however small) of dry nerd humor attached to it

you're just a whiney bitch

Re:Wow!

[AK Marc]

Sounds like hardware or serious application issues. Many of the improvements in consumer OSs have been the abandonment of application trust. Win95 would allow a bad app to crash the OS. Now, the app should be terminated, and the OS should survive. Not a problem with the OS being buggy, but being designed for a different purpose (multitasking on DOS, a non-multitasking OS).

That and I've seen crashes from things like weekend cleaners coming in and running a vacuum off the same power strip, and things like that. Power issues or minor hardware faults cause many problems. The long-uptime ones are usually in server rooms, with a little better power and physical protection. Though yes, I'm sure everyone reading this has or knows a friend with a computer with more than a year uptime running under a desk or in a closet. I had an XP machine with more than a year uptime. I stopped doing updates to make sure I didn't have to reboot to install one. Didn't have a problem until the kids got to it. Then I got to do all the updates after the arbitrary counter read a smaller number.

Re:in other news ...

[AK Marc]

The addition of the qualifier implies the answer would change for other qualifiers. What's the most used material by weight?

Re:Oh yeah? I once had a

[sysrammer]

WOW, you must be really useless!

No, that's "WOW64, you must be really useless!