Hacker News Reader

Comment by samoright | Hacker News Reader

How does running a different OS than most people can give a company an advantage? Can you elaborate this?

In my case illumos provided two things:

- zones allowed for a much higher deployment density and better utilisation of our hardware than other virtualization technology would have.

- zfs snapshots. We've integrated those into our product and when a customer messes up they now have button to instantly restore to a known good state.

Doing both of these things would have been a lot harder on another os.

A different OS can solve some of the pain points of the mainstream options. Depending on your business, the features a different OS brings could have a large impact on performance or stability.

Potential areas for improvement could be anything from filesystem to process concurrency to virtualization.

I'd see only the pain of migrating applications and learning new administration tools. Solaris was dead long before oracle killed it -- to me.

"migrating applications" -- you'd be shocked at how unix software tends to run on... unix OSes with few to no modifications.

Things like:

  * Java
  * PHP
  * Perl
  * Python
  * Ruby
  * Apache
  * Nginx
  * Varnish
  * MySqL
  * Postgres
  * Node.js
  * etc

all run just fine on a Solaris-clone. Unless your app is using very specific kernel features it will probably work fine.

They run more than just fine; usually an illumos based OS will run circles around Linux on the same hardware, and the real slap is that it won't sacrifice reliability nor correctness of operation to do that.

The comment up above in the chain was wondering whether running Solaris (or derivatives) offered any advantage. While I'm sure the packages you listed _run_ fine, how difficult would it be to find support for each when running on Solaris? You can run those softwares on Solaris, but is Solaris on the "supported platforms" list?

Not debating here, BTW; I enjoyed my time with Solaris and then its offshoots.

Edit: The thinking here only applies to systems running in production where official support is pretty much mandated.

What do you mean "find support" ? This is open source software. Your sysadmins are your first line of support. If they can't debug issues, work with the open source community, and write basic patches in C you have the wrong staff.

I've worked in places where "official" commercial-level support is required when a system is in production. In those situations, I didn't have control over the staff at any level, just pointing out it's a thing I've seen at least twice in 20 years and 4 jobs.

Well, two things here.

First: Really, the requirement for vendor 'support' is something I've always had a bit of a hard time rationalizing.. Getting a vendor in for consultancy/implementation help is a bit of a different story though and is often worth it.

Back to support.. The old "Alright, we pay RedHat or Oracle for support for when something breaks" thing.. The reality is when something does go arse over bollocks you'll get two options from your vendor (at least from sun, oracle, redhat, ibm and sap in my experience): upgrade to the latest version, or downgrade until you get a code fix from the vendor. Your critical oracle 10 db running on some older redhat point release shits itself? Not their problem. Hope you have backups. They will take file a bug internally to prevent it happening again but they can't do much more than you can internally to get things back up.

I've been in ops for almost 15 years and I still don't have a single story of a vendor 'saving the day' outside of hardware support (actually, that's not true -- once Joyent solved a problem for us by patching some servers within about an hour of us reporting a problem which remains the single greatest support experience in my life).

We worked out how to do software upgrades and rollbacks a decade ago, if one shitty linux kernel package is enough to down your business then yeah, you're doing things wrong and hopefully will learn from the experience, but paying a support fee per instance isn't going to help you recover or avoid those things.

I think we agree, all I'm trying to say is at least in my experience: You're almost always better spending your money on good staff than support contracts.

Second: In what world do you live in that your sysadmins can write kernel patches during prod outages? Maybe your reality is very different to mine, but adding/changing code has never been the solution to bad outages (and I've been through some gnarly ones, trust me) for me so far...

I can write kernel patches. Any good SA >= 10 years with C can. And we don't because it is a symptom we notice and not the problem and we are interested in a fix only as a way to survive till the cure. Kudos to the rest of your post. God bless the elders in this industry.

Ugh. Unix is absolutely the worst development target. It's clunky, ad-hoc, it uses some horrible ancient programming language and an even more horrible ancient scripting language. Like democracy, it's definitely the worst example of its type ever to have been invented.

If there was something better than Unix it would be taking over the world by storm.

If there were something better than Unix we would replace Unix with that something and keep the name. But yes, that was the joke, and no, it was not a very good one.

I'd suggest your experience|expertise is lacking. My first couple of months were bad but then I learned to appreciate the expressiveness and facility of even a bad shell language and the open horizon of how things were done. This comment seems to be classic troll or sour grapes.

It was a joke, actually. The quote I was referencing is, "Democracy is the worst form of government, except for all the others that have been tried." I actually wrote a (short) book on the ways of the Unix shell, which hopefully qualifies me to have an opinion on the matter. Although UHH is quite dated, there is and has been a great deal of legitimate criticism of Unix, and for that matter C and Bash as well. You have mistaken my opinion on the matter, but your eagerness in assigning negative qualities here is something you might want to examine. To be clear, I do consider Unix and Bash to be imperfect but essential tools for any programmer.

I think you're missing the most important application for Solaris users: Oracle (the database).

The people who is going to suffer the most from Oracle killing of Solaris are largely its own database customers. I honestly doubt many Solaris customers are running an open source stack on top of it. It's the closed source applications that will be trouble some.

Oracle wants their customers on their exadata appliances which run Linux, not Solaris. They've been pushing customers that direction for years.

No, I wouldn't (having developed since 1995) but I will state that having dealt with multi-platform builds and development for bsd and linux + darwin (until recent iterations of macos) that solaris is a pitfa, just as much as macos, and one is enough.

You can run docker containers on hardware instead of on virtual machines.

...And unlike on Linux, it treats the entire datacenter as one giant machine.

You don't have to get up at two o' clock in the morning to run fsck on a filesystem based on 30 year old concepts, for example. Or when you reboot the system, you don't have to wait 18 hours for fsck to complete because it's been more than 180 days since the last filesystem check. And I've many more examples, if you're truly interested.

I can think of the following reasons:

1. It is less profitable to develop exploits targeting a minor OS.

2. Minor OS may have some specific features that the major OS don't.

Ask Google.

Reply on news.ycombinator.com