“Oracle laid off all Solaris tech staff in a classic silent EOL of the product” • Hacker News Board

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#171

Post by binarycrusader » Sun, Sep 03, 2017, 4:46 PM UTC

gaius wrote: post #130

peoplewindow wrote: post #90

Earlier quoted context omitted.

Would it have been different if any other company had bought Sun? Solaris was competing against free, without much to justify the large added cost. It's been a very long time since I heard of anyone buying new Solaris installations.

Not really. Sun would have survived and thrived if it had thrown its weight behind Solaris x86. But they were too worried about cannibalising SPARC and when commodity kit started to beat them on price/performance they had nowhere to go. I remember when we ripped out our 3 6800s and replaced them with 9 Dells, for way more power at a fraction of the price. Would have loved to recompile on Solaris, but the hardware sav…

Not really. Sun would have survived and thrived if it had thrown its weight behind Solaris x86.

Except they did; anyone working in Solaris engineering at that time or even now could tell you that x86 was just as important as SPARC. From a technological perspective, they are completely equivalent.

For example, the ZFS Storage Appliance is x86-based, not SPARC-based.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#172

Post by X86BSD » Sun, Sep 03, 2017, 4:46 PM UTC

hedora wrote: post #158

xenophonf wrote: post #72

Earlier quoted context omitted.

Except FreeBSD is considering moving to something like launchd or systemd itself, because honestly a SMF isn't a bad idea compared to init scripts, which are rather bare bones.

SMF runs circles around systemd. I used it recently, and realized it is what systemd is trying to clone. It was kind of like learning Unix after coming from a DOS background. If FreeBSD switches to systemd, I'll stick with OpenBSD. OpenBSD is as likely to switch as they are to rewrite the kernel in rust and go.

FreeBSD will never, ever adopt systemd. That I am certain of. Even if the license wasn't an issue, and you could easily yank out all the non portable Linux code, and adopt it into BSD, the code quality, and the engineering of it would not meet BSD standards for adoption.

TrueOS just started using OpenRC and seem happy with it so far.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#173

Post by hedora » Sun, Sep 03, 2017, 4:47 PM UTC

bitwize wrote: post #106

spydum wrote: post #68

Earlier quoted context omitted.

Exactly this. I have seen hundreds of systems built by experienced gray beard Unix admins, which have been steady as rocks, some lasting 15+ years without ever a peep of trouble. however I have seen many "new" boxes built by "devops", which can't survive a single upgrade cycle. If left alone for more than a few weeks, usually eat themselves and cause an outage. On one hand, am a little thankful of the devops box, it…

Devops is doing their job. No one really cares about the uptime of a single box anymore at cloud scale. Servers are cattle, not pets. If one instance goes down, spin up a new one to take the load. P.S. this is why, contrary to graybeard whinging, boot time matters and sysvinit cannot possibly keep up with systemd in the cloud. The faster your instances boot, the less capacity you lose while they're down.

This is only really true for compute instances that don't have big caches or long warmup times.

Even then, I think you'll find you want the bare metal the instances to run on to have high uptimes (on the order of years, not minutes), since the hardware with optimal $/perf can fit more and more workloads per machine (I think this is all Moore's law is doing to help compute these days). That means you need a decreasing number of physical machines to hold your workload. At some point your "cloud" has 10 nodes instead of 1000.

Fun exercise: "cloud scale" code is typically 5-100 slower per node than single machine scale up code.

How much money would you save by consolidating smaller workloads to big machines? More importantly, how much developer productivity would you gain by eliminating network latency / marshalling for internal requests?

I think you'll see an increase of developers "coding around" devops over the next few years. I could be wrong, of course.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#174

Post by animex » Sun, Sep 03, 2017, 4:50 PM UTC

lokedhs wrote: post #81

I'm very saddened by what happens with what is left of Sun. I used to work at Sun, and the Solaris codebase is the most amazing C code I've ever worked with. I'm probably going to be accused of bias, but the Linux code is really messy compared to Solaris. Sun was already on the way down by the time I left many years ago, but what had happened since Oracle bought them has been nothing but depressing.

I feel that Sun did the same thing to the Cobalt RAQ product. Karma's a bitch.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#175

Post by acdha » Sun, Sep 03, 2017, 4:58 PM UTC

jacquesm wrote: post #167

acdha wrote: post #162

Earlier quoted context omitted.

> if you're an experienced sysadmin it spells 'fixed what wasn't broken' and it re-introduces many issues that were already thought about, taken care of and laid to rest As an experienced sysadmin that's a really sweeping claim to toss out without details or supporting evidence — the latter being especially important given the amount of hyperbole bandied about. The next largest SysV replacement was Upstart, which sol…

> As an experienced sysadmin > As a software developer So which will it be? No true Scotsman fallacy creeping in here but it seems to me that anybody that has time enough to be a developer likely isn't a full time sysadmin. Now of course there are some miracle workers out there but I've met enough syadmins to know I'm not one of them even though I can probably hold my own on the UNIX command line and manage to get th…

I've both been responsible for hundreds of systems as a full-time job and written software as a full-time job. Over a couple decades the ratio has changed from job to job but I'd also describe my style of system administration as automation-heavy and had been encouraging people to think of the job as writing code to manage systems rather than manual work since around the turn of the century so there was definitely non-trivial crossover even before the DevOps coinage became popular. (And, lest that sound vain, that wasn't exactly something I came up with. It took a long time for the automation community to go really mainstream – HPC was years ahead by necessity)

I won't claim that systemd is perfect or that I'm happy with every detail of its development history but in practice I find it's not something I need to think about very often. That was true of later Upstart releases, too, so I mostly don't get the bitterness some people have: flip a coin and either way we have a nice quality of life improvement over SysV. Yes, Red Hat carries a lot of weight but they also employ a ton of open source developers so it's not like that's unearned.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#176

Post by hedora » Sun, Sep 03, 2017, 5:02 PM UTC

pjmlp wrote: post #13

nailer wrote: post #9

Earlier quoted context omitted.

Every major Linux distro uses systemd. I know its opponents are vocal but a bunch of us are silently enjoying the simplicity of .service files and systemd timers.

I guess many that are against it, would rather have a pure UNIX V installation, eventually running twm.

I'd like something better than UNIX V and that I can understand.

In my experience, systemd fails on both points. For example, and understanding of user permissions under systemd is probably beyond 99% of developers' expertise.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#177

Post by notacoward » Sun, Sep 03, 2017, 5:02 PM UTC

shadowtree wrote: post #119

xroche wrote: post #113

Earlier quoted context omitted.

> but what had happened since Oracle bought them has been nothing but depressing Oracle is nothing but a cancer. Everything they touch turn into goo. This is not the first company to be killed by Oracle acquisition. And not the last. And don't let me started on the ridiculous range-check trial: this sums up the disgusting state this company has fallen into.

ORA is the elephant's graveyard of software. Once something gets bought by them, you know it is done. Slowly, but surely. They perform a function akin to the maggots that destroy cadavers in nature. Part of the overall ecosystem. ORA stopped being a tech co a while ago, now it is a finance play. Use cash to buy a business for its locked in customers, gut it to squeeze max money out of it until last customer is gone.…

> ORA is the elephant's graveyard of software.

I think that's a more apt description of CA, BMC, or Symantec. Places where tired old software goes to die a quiet death. What Oracle does is worse: kill software that still has plenty of life in it. I've seen them do it by acquisition, and I've seen them do it by stealing code or ideas from partners (personally, twice). So they're not so much a graveyard as a slaughterhouse for software.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#178

Post by vram22 » Sun, Sep 03, 2017, 5:17 PM UTC

pjmlp wrote: post #11

exBarrelSpoiler wrote: post #3

Earlier quoted context omitted.

Imagine if Solaris could be used as a kernel for a mobile OS...

Sun used to sell Toshiba laptops with Solaris x86 pre-installed.

Sun also bought Cobalt Networks (for $2 billion), the company behind the Cobalt Qube, soon after their successful IPO. The Qube was a cool Unix server appliance, targeted at ISPs, etc. [1] I worked for a short while at a startup that used one of them.

https://en.wikipedia.org/wiki/Cobalt_Qube

https://en.wikipedia.org/wiki/Cobalt_Networks

[1] Sun's buy of Cobalt had bad timing, since the dot-com bust happened soon after.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#179

Post by Someone » Sun, Sep 03, 2017, 5:19 PM UTC

justincormack wrote: post #30

Someone wrote: post #27

Earlier quoted context omitted.

Legal concerns: do we really own this code? If there is code in there that turns out to be copy-pasted from somewhere else, open sourcing makes it more likely that people will find it. That could be expensive (e.g. when some BigCo owns the copyright on code they have been selling for decades) and/or have even more serious consequences (e.g. when there's a GPL-licensed code fragment in there, and they linked it with a…

But it was already open sourced once before, so much of that work was done already.

Valid point, so here is a similar, but different reason: patents.

They may fear releasing the source opens them for patent lawsuits or may have patents they aren't willing to give up, and fear that open sourcing it without any patent clause will not give them much goodwill.

Re: “Oracle laid off all Solaris tech staff in a classic silent EOL of the product”

#180

Post by yourapostasy » Sun, Sep 03, 2017, 5:21 PM UTC

kator wrote: post #40

binaryapparatus wrote: post #20

Earlier quoted context omitted.

I am 46 years old, with over 25 years of programming and system administration experience. I've been here before internet existed. You better believe I know what I am talking about. I couldn't care less about karma kid.

LOL I'm older and have 35 years of experience in the technology. Doesn't mean for one hot second I think I can just puff my chest up about a topic and blow people off when they ask a perfectly good question. For me the jury is still out on systemd. My biggest concern is it seems to be slowly taking over everything and thus violating the core unix philosophy of "do one thing really well". It feels like systemd was sta…

> My biggest concern is it seems to be slowly taking over everything and thus violating the core unix philosophy of "do one thing really well".

The larger attack surface, reduced "git 'r done"'ess when you're in the midst of a hot outage, and increased complexity to trace what happens give me concerns. Some touched upon in this StackExchange [1] conversation thread, but lots of good threads elsewhere on the Net along these and other lines. Personally, I'd rather see the entire idea of "booting" be looked at again.

The reason sysadmins value the "git 'r done" aspect of System V init is because servers are not booted frequently. But init scripts are changed more frequently than servers are booted, and business application teams forbid booting the server more than utterly, absolutely, necessary; and the sysadmins wanting to boot to test a modification to the init script doesn't count. Dev/QA/Pre-prod change control environments help, devops-based source control discipline helps, but the next time a server is booted is always at least a "sideways-glancing-to-see-what-breaks" moment for many a sysadmin. When the startup sequence breaks somewhere, it becomes a hot outage, and especially if correcting it requires application-specific domain expertise, outside the OS. In the middle of such a hot outage, the ability to get closer to the problem domain within the shell script is appreciated. Systemd's init compatibility indirection layer helps, and hopefully, some thought in the future is given to streamlining this layer.

The entire notion of "booting" has rubbed me the wrong way for an increasing amount of time, though. Microkernels tried to address this, but they never caught on. Solaris and AIX try to address this, and Linux is exploring this, with their live kernel migration features, but they don't really do much to help higher up the stack. The best I can do to mitigate this itch for the time being is highly-available three-node clusters, and regularly moving the application to one of the opposite nodes, booting the inactive node, and testing changes to that boot, and the aforementioned devops-orientation and source control. Having an OS that lets me "re-home" a running application Tandem-Kernel-like/VMWare-Live-Migration-like, to a newly-"booted" state of the OS though, would be the bees' knees.

[1] https://security.stackexchange.com/questions/167721/what-are...