Slashdot Mirror
Oracle Staff Report Big Layoffs Across Solaris, SPARC Teams (theregister.co.uk)
Simon Sharwood, reporting for the Register: Soon-to-be-former Oracle staff report that the company made hundreds of layoffs last Friday, as predicted by El Reg, with workers on teams covering the Solaris operating system, SPARC silicon, tape libraries and storage products shown the door. Oracle's media relations agency told The Register: "We decline comment." However, Big Red's staffers are having their say online, in tweets such as the one below. "For real. Oracle RIF'd most of Solaris (and others) today," an employee said. A "RIF" is a "reduction in force", Oracle-speak for making people redundant (IBM's equivalent is an "RA", or "resource action"). Tech industry observer Simon Phipps claims "~all" Solaris staff were laid off. "For those unaware, Oracle laid off ~ all Solaris tech staff yesterday in a classic silent EOL of the product."
Can the codebase be recovered?
Doesn't need to be. Illumos is the open fork of (not so) OpenSolaris.
There's still a lot of valuable code in the closed version of Solaris. ZFS enhancements come to mind.
ZFS enhancements come to mind.
After the split with OpenSolaris, ZFS development moved to the Illumos project and OpenZFS grew out of it.
In case anyone wants more insider info. https://www.thelayoff.com/orac...
putting the 'B' in LGBTQ+
After Solaris was open sourced, there seemed to be a time when the use of Solaris could potentially expand greatly. Once Ellison closed the code again, there was no hope at all. Ellison should be blamed completely for this.
Proprietary ZFS also grew a number of features and enhancements. For example, OpenZFS is just growing the encryption support while the proprietary ZFS has had it for several years.
This is very true.
This wasn't just Sun's problem, IBM had similar issues with the AIX Power servers. The price/performance of Java on x86 was far better than anything that Sun or IBM could offer. They were still stuck with the mindset of selling expensive mid-range type systems. They could offer better scaling, with more cores in a single box, but when you could have a distributed application, with many small servers, the old vendors couldn't compete.
Once Redhat went public and management were able to convinced that Linux was a real alternative, instead of buying 4 AIX servers of $75k each, I was able to get 12 Linux x86 servers for $4k each (rack mounted, so a little bit expensive). The price for Sun SPARC servers were cheaper than the AIX servers, but still way more expensive than x86 servers.
The Linux servers were multiple times faster for the Java applications that they had to run, for just over 1/2 the price of a single AIX box.
"The best part? I became an ordained minister while not wearing pants." -- CleverNickName
He bought it mainly because of Java. Oracle has a huge investment in Java and there was no way in hell he could afford to let it die or, worse yet, let it go to IBM.
Solaris was a nice bonus because Oracle also had lots of investment in that hardware/software platform for it's own servers. From where I sit, I saw a gradual move to Oracle Linux over the years but I can not say wether that is responsible for dropping Solaris/Spark.
There was a time I had a Solaris virtual box. Mostly unused but was useful when I needed to install a particular server instance for the applications I was doing at the time. Nowadays, I have an Oracle Linux virtual machine on which runs one of our development tools, for our App development. Other members in the team have their own Oracle Linux virtual machine to host dev or qa instances of the server for our App development use.
Haven't seen an OpenSolaris box in years, but I know one of our training center in MDC has (had?) a few boxes on there. Not sure they are still there. Been ages since I walked in that office.
WHY would any SANE programmer put business logic into the model layer?
To uniformly enforce rules when accommodating multiple applications accessing the same data.
Another reason is that the database will usually be the longest living part of the software architecture.
In terms of things being tightly coupled, defining a set of stored procedures for data access hardly makes the application tightly coupled. Using raw SQL tightly couples your application to the schema. If the schema needs to change for database reasons the stored procedure layer could prevent you from having to modify the applications.
Yes, there are other ways to accomplish the same thing but it's not an insane decision.