Live data from Hacker News

The sudden death and eternal life of Solaris

dtrace.org

261–270 of 279 posts

Re: The sudden death and eternal life of Solaris

#261
post #211
post #204

Earlier quoted context omitted.

This preserves the structure better: > As someone who's never used Solaris [...] I'm curious: can someone [...] Notice that you left out the subject (I), left out the verb (am), and replaced a colon with a comma!

> Notice that you left out the subject (I), left out the verb (am), and replaced a colon with a comma! No, I didn't left out anything important to the structure nor did I replace a colon with anything. The thing is that you and I were looking at two different sentences, because OP silently edited his comment (I only noticed that now). The original sentence was "As someone who's never used Solaris or looked into its m…

Fine :) The fact remains: given you knew what was meant, you could at least have answered the question as intended, in addition to nitpicking. (I would never tell someone to stop nitpicking. Well, almost never.) See also https://xkcd.com/1576/

Re: The sudden death and eternal life of Solaris

#262

Earlier quoted context omitted.

I dunno. I used it a little in college in the early 2000s, along with anything else I could get my hands on, and it seemed to me to be user hostile even by Unix standards. When I worked with Linux, *BSD etc. or Irix, things tended to make more sense. It was difficult to get much experience with Solaris or the other commercial Unixes because you usually had to have particular hardware. Even when Solaris became free an…

I guess you never had the pleasure of using a Pyramid Technology Corporation 90x RISC-based minicomputer running OSx, which supported BSD and System V at the same time in parallel universes, and had patented "conditional symbolic links" to support dynamically switching between the two by changing an environment variable. https://en.wikipedia.org/wiki/Symbolic_link#Variable_symboli... >Pyramid Technology's OSx Operati…

Thank you for being "discrete" as asked in the last paragraph from 1986. That was a good read.

Although less extreme, Solaris multiarch was not exactly always a picnic.

From when it started becoming a lot less insane:

https://www.perkin.org.uk/posts/multiarch-package-support-in...

Re: The sudden death and eternal life of Solaris

#263
post #169

There seems to be a lot of odd nostalgia for Solaris in the comments here and on twitter. I think that's missing the point of the article. Yes, Oracle Solaris is dead. But illumos is better, open source, alive and here to stay. You can use illumos today, right now, and have your ZFS, mdb, DTrace and zones. It really is open source and we're a community using and improving it. For 7 years now already. As illumos is on…

Things make a lot more sense now. For having been interested tangentially in OpenSolaris (I still have its "bible" as a monitor stand) I never knew Illumos was the kernel, and other OSes based on it. I assumed all the different Solaris spinoffs were complete forks, and thus assumed they were all dead or dying. I will say the wikis are not inspiring; many on Illumos, OpenIndiana and SmartOS have pages last edited mult…

Oh yes, the wikis definitly do need some love. Documentation is beeing worked on as far as I know.

A lot more of activity is going on in irc on freenode, so if you start playing with your lab server or are just interested in general you might want to drop by in #illumos or #smartos.

Re: The sudden death and eternal life of Solaris

#264
post #226

Earlier quoted context omitted.

"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.

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 th…

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.

Re: The sudden death and eternal life of Solaris

#265
post #226

Earlier quoted context omitted.

"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.

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.

Re: The sudden death and eternal life of Solaris

#266
post #264

Earlier quoted context omitted.

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 th…

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.

Re: The sudden death and eternal life of Solaris

#267

Earlier quoted context omitted.

I guess you never had the pleasure of using a Pyramid Technology Corporation 90x RISC-based minicomputer running OSx, which supported BSD and System V at the same time in parallel universes, and had patented "conditional symbolic links" to support dynamically switching between the two by changing an environment variable. https://en.wikipedia.org/wiki/Symbolic_link#Variable_symboli... >Pyramid Technology's OSx Operati…

Thank you for being "discrete" as asked in the last paragraph from 1986. That was a good read. Although less extreme, Solaris multiarch was not exactly always a picnic. From when it started becoming a lot less insane: https://www.perkin.org.uk/posts/multiarch-package-support-in...

I'm the one who got in trouble for forwarding that to a mailing list that leaked it to Pyramid, but in my defense, Pete did say: "Tell your friends and loved ones. We are considering calling Pyramid to see if they want in on the action (but we'll only call them after we disable the remote diagnostic port)." Better to ask for forgiveness, after you already assumed you had permission. Maybe Pete was rightfully pissed because he didn't get the remote diagnostic port disabled in time.

Re: The sudden death and eternal life of Solaris

#268

At the end of the day, Sun/Oracle has to be able to make revenue from Solaris for them to keep paying those peoples' salaries. Is your startup / company deploying on Solaris? Nope of course you aren't - who is?! Pretty much nobody nowadays - w3techs.com shows Solaris at 0.0005% for webservers for example. Everyone talks about how great it is(to be sure there are some small bits that are pretty dang amazing) - yet for…

We are for sure.

We run a number of physical hosts using SmartOS (only 20 or so, but they're quite big (512GB, quads)) and on top of those we use a mix of KVM and zones (both solaris and lx) for various workloads (around 400 zones/vms).

It's easily been the correct choice for us. YMMV.

Re: The sudden death and eternal life of Solaris

#269
post #264

Earlier quoted context omitted.

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 th…

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.

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...

Re: The sudden death and eternal life of Solaris

#270
post #226

Earlier quoted context omitted.

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.

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.
Post reply on HN