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

239 comments

  1. All Solaris Staff? by that+this+is+not+und · · Score: 1

    Can the codebase be recovered? There's a lot of it.

    1. Re:All Solaris Staff? by theweatherelectric · · Score: 5, Informative

      Can the codebase be recovered?

      Doesn't need to be. Illumos is the open fork of (not so) OpenSolaris.

    2. Re:All Solaris Staff? by Anonymous Coward · · Score: 2, Informative

      There's still a lot of valuable code in the closed version of Solaris. ZFS enhancements come to mind.

    3. Re:All Solaris Staff? by theweatherelectric · · Score: 5, Informative

      ZFS enhancements come to mind.

      After the split with OpenSolaris, ZFS development moved to the Illumos project and OpenZFS grew out of it.

    4. Re:All Solaris Staff? by Z00L00K · · Score: 2, Insightful

      As I see it Solaris is pretty stagnant since at least a decade. Most new development of *NIX environment has been under Linux and different BSD variants.

      There may be certain applications that are Solaris specific, and it's probably a few of those that could be of interest to port to other environments if they aren't ported already.

      But the days when Solaris was a leading significant factor in the *NIX world ended some 20 years ago.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    5. Re:All Solaris Staff? by avgapon · · Score: 2, Informative

      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.

    6. Re:All Solaris Staff? by The123king · · Score: 1

      Download your favorite text editor and get to work then!

      --
      If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
    7. Re:All Solaris Staff? by OneHundredAndTen · · Score: 1

      Download your favorite text editor and get to work then!

      Why? There are many people out there who do not have the inclination, desire and capabilities to do so, but they still want to use a good product. Supercilious answers like yours make the open source developers communities come across as a bunch of sanctimonious assholes.

    8. Re:All Solaris Staff? by Anonymous Coward · · Score: 0, Funny

      Fuck you for not using the Oxford comma.

    9. Re:All Solaris Staff? by Anonymous Coward · · Score: 0

      It actually seems like a completely reasonable response to someone demanding something for nothing...

    10. Re:All Solaris Staff? by PCM2 · · Score: 1

      Most new development of *NIX environment has been under Linux and different BSD variants.

      And yet a lot of that "new development" seemed to be aimed at doing things Solaris already did. Meanwhile, I doubt many Solaris admins are interested in things like systemd or open source 3D graphics drivers.

      --
      Breakfast served all day!
    11. Re:All Solaris Staff? by war4peace · · Score: 1

      But it's not.
      The same argument can be used the other way around. An open product keeps being developed for as long as there's demand for it. If all demand stops, development usually stops soon after, and sometimes it stops even when there's still some demand left. So by this equally-twisted logic, you should thank that "someone demanding something for nothing".

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
    12. Re:All Solaris Staff? by Anonymous Coward · · Score: 0

      er, that's because they are

  2. Rule #1 by UndyingShadow · · Score: 5, Funny

    "Don't make the mistake of anthropomorphizing Larry Ellison." -Bryan Cantrill

    1. Re:Rule #1 by ShanghaiBill · · Score: 4, Insightful

      "Don't make the mistake of anthropomorphizing Larry Ellison." -Bryan Cantrill

      Larry can be very cold hearted, but I can't fault him for this. Sparc/Solaris was a great choice in the 1980s, a reasonable choice in the 1990s, and a bad choice ever since. There can't be much more than a handful of legacy customers left. I am surprised that it took this long to finally die.

    2. Re:Rule #1 by Tablizer · · Score: 1

      "Don't make the mistake of anthropomorphizing Larry Ellison." -Bryan Cantrill

      I just read the book about Oracle and Larry by Mike Wilson. Larry is basically a smarter Trump.

    3. Re: Rule #1 by Anonymous Coward · · Score: 0

      I still like sparc and would like an updated sparc machine. I don't care about solaris anymore though.

    4. Re: Rule #1 by Bing+Tsher+E · · Score: 1

      OpenBSD is still pretty strong on Sparc, I would suppose. It's Theo's arch after all.

    5. Re:Rule #1 by __aaclcg7560 · · Score: 0, Troll

      "The Difference Between God And Larry Ellison*: Inside Oracle Corporation" by Mike Wilson (* "God doesn't think He's Larry Ellison.").

      Was this book that had the handyman turning off the water and Larry Ellison screaming that he was in the shower with two women?

      Larry is basically a smarter Trump.

      Larry is probably not into golden showers.

    6. Re:Rule #1 by Anonymous Coward · · Score: 0

      Look, at least fix the horrible typos and grammar mistakes if you're just going to copy/paste.

      We use Chris (a.k.a creimer) picture in our document

      Chris's. Or Chris'. But for fuck's sake put an apostrophe.

      because he his one of the hardest case

      Because he is, not his. Cases, not case.

    7. Re:Rule #1 by Anonymous Coward · · Score: 3, Informative

      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.

    8. Re:Rule #1 by Tailhook · · Score: 2

      This. Solaris could have gone far, but for the people that owned it.

      --
      Maw! Fire up the karma burner!
    9. Re:Rule #1 by Anonymous Coward · · Score: 0

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

    10. Re:Rule #1 by Bing+Tsher+E · · Score: 0

      Larry is probably not into golden showers.

      Don't drag your private life into the discussion, creimer.

      Oh, and your link to Mike Wilson's book? It's quite an old book at this point. It would be a terrible mistake to buy it off an Amazon.com link.

      ABE Books has it available for $3.48 with free shipping.

    11. Re:Rule #1 by Anonymous Coward · · Score: 0

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

      English, motherfucker, or shut the fuck up.

      "YOU'RE still.....YOUR case...."

    12. Re: Rule #1 by Anonymous Coward · · Score: 0

      Please stop posting affiliate links, it's ruining Slashdot, you're no better than a bot.

    13. Re:Rule #1 by UltraZelda64 · · Score: 2

      Then why the fuck did he buy it? Maybe his company could have done less of a dick move by just selling the Sun properties that they were not interested in, like Solaris, so they could be given an actual, proper chance. Fuck Oracle.

    14. Re:Rule #1 by Tablizer · · Score: 1

      Yes, that's the title, but I don't remember that particular story. But if Larry told it, you have to take it with a big grain of salt, for he's a habitual embellisher.

    15. Re:Rule #1 by Anonymous Coward · · Score: 0

      Considering that there was only a single SPARC release in the 80's and Solaris didn't come out until the 90's, I'd say your timeline is about a decade off.

      When Solaris was released as Solaris 2, the original BSD-based SunOS was renamed Solaris 1, but it was a completely different OS.

      dom

    16. Re:Rule #1 by Anonymous Coward · · Score: 0

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

      You are still in "Special Ed" Chris, you case inspired Martin Scorsese for the movie "Shutter Island":
      https://en.wikipedia.org/wiki/...

      http://www.apotekdewasa.com/
      https://jualtitangeloriginal.com/
      https://jualtitangeloriginal.com/alamat-agen-jual-titan-gel-asli-original/
      https://jualtitangeloriginal.com/jual-titan-gel-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-cream-titan-gel-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-viagra-usa-obat-kuat-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-alat-bantu-sex-penis-sakky-elektrik-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-alat-bantu-sex-penis-tekuk-manual-di-jakarta/
      http://www.apotekdewasa.com/alamat-jual-procomil-spray-obat-kuat-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-opium-spray-obat-perangsang-wanita-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-maxman-tablet-obat-kuat-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-cialis-80mg-obat-kuat-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-alat-bantu-sex-penis-getar-goyang-di-jakarta/
      http://www.apotekdewasa.com/agen-jual-penirum-asli-obat-pembesar-penis-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-klg-obat-pembesar-penis-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-hammer-of-thor-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-vimax-canada-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-pembesar-penis-testo-ultra-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-parasit-hermuno-intoxic-asli-di-jakarta/
      http://www.apotekdewasa.com/alamat-agen-jual-obat-kuat-viagra-usa-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-agen-jual-obat-pembesar-penis-forex-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-agen-jual-anabolic-rx24-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-agen-jual-obat-kuat-cialis-80mg-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-pembesar-penis-klg-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-kuat-semprot-procomil-spray-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-obat-perangsang-wanita-opium-spray-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-agen-jual-titan-gel-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-hammer-of-thor-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-vimax-asli-di-samarinda/
      http://www.apotekdewasa.com/alamat-toko-jual-cream-titan-gel-asli-di-pekanbaru/
      http://www.apotekdewasa.com/agen-jual-vakum-alat-pembesar-penis-asli-di-balikpapan/
      http://www.apotekdewasa.com/agen-jual-hammer-of-thor-asli-obat-pembesar-penis-di-balikpapan/
      http://www.apotekdewasa.com/agen-jual-vimax-asli-obat-pembesar-penis-di-balikpapan/
      http://www.apotekdewasa.com/agen-jual-hermuno-intoxic-asli-obat-parasit-di-balikpapan/
      http://www.apotekdewasa.com/agen-jual-titan-gel-asli-obat-pembesar-penis-di-balikpapan/

    17. Re: Rule #1 by K.+S.+Kyosuke · · Score: 1

      Isn't Sparc's current strength large machines with many sockets and cores, something OpenBSD seems particularly bad at?

      --
      Ezekiel 23:20
    18. Re: Rule #1 by Anonymous Coward · · Score: 0

      Have you stopped raping your neighbor's goats yet?

    19. Re:Rule #1 by Anonymous Coward · · Score: 1

      With Solaris 2 Sun dropped engineering and went corporate. Instead of the experienced sales reps who took engineers out to lunch at the local deli, and got them better pricing when budgets were tight, it was pretty blondes and bland presentations in company meeting rooms. No deals. By the early 90's Sun had some altitude, but like the minis before them, their high price was sucking the fuel keeping them aloft, while PCs we're buzzing below and gaining altitude. It's been a slow deadstick landing for Sun since.

    20. Re:Rule #1 by ShanghaiBill · · Score: 5, Insightful

      Then why the fuck did he buy it?

      To kill MySql, which was a long term threat to Oracle's core business.

      Maybe his company could have done less of a dick move

      Without dick moves, Oracle wouldn't be Oracle, and Larry certainly wouldn't be Larry. Being a dick is his core competency.

    21. Re:Rule #1 by angel'o'sphere · · Score: 1

      No idea about SPARC.
      However Solaris is running everywhere.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    22. Re:Rule #1 by thesupraman · · Score: 5, Insightful

      MySQL? A Threat a real database? Umm. No.

      PostgreSQL perhaps, but not MySQL.

      Just because its popular with 'toy database' applications (where the db is really just slightly glorified read only storage) doesnt mean it is a threat or oracle - different horses for very different courses.

    23. Re:Rule #1 by Anonymous Coward · · Score: 0

      MySQL is in much better shape now than before the Sun acquisition.

    24. Re: Rule #1 by Anonymous Coward · · Score: 0

      Seek help.

    25. Re:Rule #1 by Anonymous Coward · · Score: 5, Insightful

      MySQL? A Threat a real database? Umm. No.

      A threat to real database needs, no. But a threat to real database sales, yes, at least in the eyes of people who see any alternative as a lost sale. Sure, MySQL is mostly a replacement for a structured file, but that's still one replacement for a structured file that Oracle wasn't paid for.

      It's not much different than the kind of mind set that would claim that a 10 year old a yearly allowance of $1200 copying a bunch of MP3s is a loss to the music industry of $12 million.

    26. Re:Rule #1 by Anonymous Coward · · Score: 0

      > Just because its popular with 'toy database' applications (where the db is really just slightly glorified read only storage) doesnt mean it is a threat or oracle

      You clearly just described that it was and still *is*. PostgreSQL isn't even something Oracle has tried to combat (other than listing it with MySQL in the same breath as a minor player). The attempt to paint the engines in some sort of niche that isn't commensurate with history, is obvious salt.

      AWS and Oracle and plenty of other industries must all be technically incompetent. You are underappreciated for your brilliant insights. Yeah, that's the ticket. Keep seasoning that MySQL sauce. SMH

    27. Re:Rule #1 by TheRaven64 · · Score: 5, Insightful

      PostgreSQL is less of a threat to Oracle than MySQL. If you start building a system with PostgreSQL, you have a reliable database with a decent query optimiser and you'll end up putting a lot of logic into the database. Once you grow to a big enough size that you might be able to afford Oracle, they send along salesmen and convince your least competent C?O that your data would be a lot safer if you migrate to a proper database and they provide migration tools to do this. They can probably demonstrate some speedups from their custom filesystem and query optimiser. On the other hand, if you start with MySQL, you end up using the database as little more than a key-value store and put most of the logic outside of the database. It's much harder to demo a place where Oracle is an improvement because your bottleneck is the application logic that's doing a load of redundant database queries, not the database itself.

      --
      I am TheRaven on Soylent News
    28. Re:Rule #1 by Anonymous Coward · · Score: 3, Interesting

      Not sure if you've noticed, but Oracle have spent the last 2 years pulling volume discounts from under some pretty big companies. My entire multinational has set a deadline to remove all use of Oracle, and I know we're not the only ones migrating from Oracle to Postgres

    29. Re:Rule #1 by TheRaven64 · · Score: 5, Interesting

      I didn't, but I'm not surprised. Last time I spoke to someone at Oracle, they said that the revenue from the DB was up, but they had very few new customers. Their real problem is Moore's law and friends. In the early '90s, payroll for a moderately large company took a serious database on high-end hardware to manage, with several hours of compute time to complete the payroll calculations each week. Now, that same company is maybe 10 times the size, but you can buy a computer more than 100 times better in terms of RAM, storage capacity, storage speed, and processor speed, for a few hundred dollars. On a modern machine, you don't need carefully optimised queries and carefully designed on-disk data structures - you can probably fit the whole thing in RAM and run the computations in Lua and still get the whole thing done in a second or two. At one end of the market, most customers can now run their systems with cheap commodity hardware and software. At the other end of the market, companies like Facebook and Google have more data than Oracle can easily handle and couldn't afford Oracle license fees even if there was a viable Oracle product for them to buy. The middle is gradually shrinking.

      --
      I am TheRaven on Soylent News
    30. Re:Rule #1 by CaptnCrud · · Score: 1

      SPARK and Solaris was still the mainstay at the last large research institution I worked at up until a year ago when the first rumblings came out...

    31. Re:Rule #1 by azrael29a · · Score: 2

      Then why the fuck did he buy it? Maybe his company could have done less of a dick move by just selling the Sun properties that they were not interested in, like Solaris, so they could be given an actual, proper chance. Fuck Oracle.

      To sue Google for Java patent infringement in Android. But that plan has failed.

    32. Re: Rule #1 by hord · · Score: 2

      Lots of shared, hyper-threaded cores. The performance on them is abysmal. They started to bank on marketing the number of cores rather than making cores that perform so you get CPUs with 128 "cores" based on 4 CPU dies that take 10x as long to gzip/gunzip and other simple tasks.

    33. Re:Rule #1 by hord · · Score: 2

      You probably still have large SPARC sales due to legacy applications requiring it as part of the stack. This is changing, but I used an ERP that only gave requirements for Sun SPARC/Solaris with Oracle databases and this drives purchasing decisions. We tried for years to convince them to switch to Linux with all kinds of performance metrics. You lose your support contract when doing so, however.

      Now that stuff is moving into the cloud, SPARC has no real reason to exist. It was already pretty crippled compared to x86 for general purpose stuff.

    34. Re:Rule #1 by Anonymous Coward · · Score: 0

      ""YOU'RE still"

      What the hell do you think that apostrophe is doing? You're = you are.

    35. Re: Rule #1 by Anonymous Coward · · Score: 0

      Why? What's wrong with your goat?

    36. Re: Rule #1 by Anonymous Coward · · Score: 0

      Solaris was a great choice right up to the day Oracle bought the company.

    37. Re: Rule #1 by Anonymous Coward · · Score: 0

      Oh yes you can, if there's one thing you excel at, it's ruining other people's enjoyment.

      Now, about your goat, why don't you take it to the vet, that way you don't need to ask me to be next in line at the neighbor's?

    38. Re:Rule #1 by rholtzjr · · Score: 1

      And next in the cross hairs, Java. It seems that everything they touch becomes a lock in type technology to their specific design. Yea, their database is good, but that is about it. Everything else they touch seems to become a cluster-f$#k that eventually dies. But who is to say that this was not their plan all along.

    39. Re:Rule #1 by MouseR · · Score: 4, Informative

      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.

    40. Re:Rule #1 by MouseR · · Score: 2

      Forgot to mention: those are my thoughts and impression. Not an official Oracle statement. I claim not to know the inner workings of management decisions.

    41. Re:Rule #1 by rholtzjr · · Score: 2

      PostgreSQL is less of a threat to Oracle than MySQL. If you start building a system with PostgreSQL, you have a reliable database with a decent query optimiser and you'll end up putting a lot of logic into the database. Once you grow to a big enough size that you might be able to afford Oracle, they send along salesmen and convince your least competent C?O that your data would be a lot safer if you migrate to a proper database and they provide migration tools to do this.

      Here is the big question. WHY would any SANE programmer put business logic into the model layer? That would tightly couple your database engine to the other layers of the application. Once a more viable solution is available, it may have already become too cost prohibitive to migrate to the next technology. We see this now with a lot of mainframe centered companies. Don't get me wrong, most mainframe based companies have a very highly tuned and efficient solution, but as technology changes, where does that leave them?

    42. Re: Rule #1 by Anonymous Coward · · Score: 0

      The TOS doesn't cover every annoying edge case. I guess taking your karma to nothing is the only option since Slashdot management is always MIA.

    43. Re:Rule #1 by Anonymous Coward · · Score: 0

      In the MVC architecture, it's better to put business logic in your models than in your controllers or views.

    44. Re:Rule #1 by Anonymous Coward · · Score: 0

      I've not checked the catalog recently but a number of exadata machines were available as solaris or unbreakable linux. I suspect that those that cared still went the linux route.

      Going further back, Oracle did inherit and progress with the sparc lifecycle and did have plans for actively continuing with it.

    45. Re:Rule #1 by Anonymous Coward · · Score: 0

      Once you grow to a big enough size that you might be able to afford Oracle, they send along salesmen and convince your least competent C?O that your data would be a lot safer if you migrate to a proper database and they provide migration tools to do this.

      Your statement about selling to the least competent executive is certainly true. I've seen gangs of IBM salesmen do the same thing pushing Websphere and DB2. But with the computing power available on commodity hardware or cloud vendors I really don't think you give up any throughput or security using Postgresql.

    46. Re:Rule #1 by Anonymous Coward · · Score: 5, Informative

      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.

    47. Re:Rule #1 by Kjella · · Score: 1

      On a modern machine, you don't need carefully optimised queries and carefully designed on-disk data structures - you can probably fit the whole thing in RAM and run the computations in Lua and still get the whole thing done in a second or two. At one end of the market, most customers can now run their systems with cheap commodity hardware and software. At the other end of the market, companies like Facebook and Google have more data than Oracle can easily handle and couldn't afford Oracle license fees even if there was a viable Oracle product for them to buy. The middle is gradually shrinking.

      Well for companies like Facebook and Google you don't care that the social feed or search index is only kinda updated by computer standards or that different people see slightly alternate versions. There are a lot of markets where you don't have that luxury, that ticket is either sold or not sold. But yes I agree those kinds of transaction processing markets don't scale the way computer hardware does, my local cinema got roughly as many seats as it had last decade. Stadiums and arenas don't get bigger. Even financial transactions (outside high frequency trading) and Amazon's inventory don't increase that exponentially. Most of the real crunching power is now going into "softer" processing of big data, voice recognition, robot vision etc.

      --
      Live today, because you never know what tomorrow brings
    48. Re:Rule #1 by Penguinisto · · Score: 2

      Same story here, really. At a previous employer, I fed and cared for a metric ton of ldoms* running on Sparc T-3 iron, as well as other (slightly older) Sparc pizza boxes running a ton of zones. The big reason they existed was to test the product on the Solaris/Sparc platform under various incarnations (from Solaris 7 to latest/greatest, which was IIRC 11.x at the time)... and that was about it.

      Anything they actually cared about (business-wise) sat on Linux and/or Windows boxen.

      * for those who were unaware, apparently Oracle decided they wanted to compete with VMWare at one point in time, so they created something called Logical Domains (ldoms). Think of everything you ever thought to be frustrating about vSphere, make it 10x worse (especially virtual networking), then build it with a CLI-only interface. Let's just say that IBM's version of it ( lpars ) were 100x more enjoyable to build/maintain.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    49. Re:Rule #1 by Anonymous Coward · · Score: 0

      Look, at least fix the horrible typos and grammar mistakes if you're just going to copy/paste.

      What do you expect, she's a public education product...

    50. Re: Rule #1 by Eravnrekaree · · Score: 1

      I doubt that is a problem on servers where you have to handle thousands of concurrent sessions. It would apply more a desktop machine where the zip is the only process you are running.Where you have one sequential process running on the entire machine, of course the extra cores are wasted. That is not an issue on a high volume server.

    51. Re:Rule #1 by Anonymous Coward · · Score: 0

      Switching database platforms is very rare at places where the database is actually important. If you're paying for Oracle, then you probably want to use Oracle's features, which often means implementing business logic using those features, rather than writing lowest common denominator SQL and relying on an ORM layer (which can often turn out to be a very bad way of doing things).

    52. Re:Rule #1 by theendlessnow · · Score: 1

      MySQL? A Threat a real database? Umm. No.

      PostgreSQL perhaps, but not MySQL.

      Just because its popular with 'toy database' applications (where the db is really just slightly glorified read only storage) doesnt mean it is a threat or oracle - different horses for very different courses.

      You need to understand that the "toy" database is deployed much more than Oracle today (including small companies like Facebook, Pinterest, Github). Not bad for a "toy". Doesn't matter if it is a "toy" or not, it's being used by major systems that would have been running Oracle. The good news is that Oracle's expensive attempt to kill MySQL forced the creation of MariaDB (used by Google and many others) and other alternatives, and we all know that Oracle's ploy against HP produced a huge interest in PostgreSQL. Everybody is winning, well except for Oracle.

      Don't ever pull a sword on your customer base. It's just a bad business strategy.

    53. Re:Rule #1 by DuckDodgers · · Score: 1

      Actually, the Graal project that Oracle is funding for Java is pretty cool. And the only thing bad about handing JavaEE to the Apache Software Foundation was that Oracle should have done it sooner.

      Java is painful to use, but it's around for the long haul - especially since Oracle couldn't remove OpenJDK even if they wanted to. The JVM, though, is a really useful platform, and Oracle has not yet managed to screw that up.

    54. Re: Rule #1 by hord · · Score: 2

      T-series SPARC architecture is only good for one thing: serving static web pages. You will get horrid performance for anything else. I know because we ran all kinds of stuff on them including web servers, databases (Oracle), and infrastructure. You are getting a slow, 4-CPU machine that "hyperthreads" to 128 cores with little to no cache. No, it is a horrible platform that needs to sink to the bottom of the digital ocean regardless of "high volume" and "server" labels. It was designed for transactional processing and fails. Don't take my word for it... ask the entire IT industry what they think.

    55. Re:Rule #1 by Anonymous Coward · · Score: 0

      it was pretty blondes

      You say that like it was a bad thing.

    56. Re:Rule #1 by DuckDodgers · · Score: 1

      Most companies start with a 'toy database' for their 'toy application' and then have the application and the database expand in volume and features used as the business grows. And for an awful lot of companies, the growth never passes the size in which Oracle or something like it becomes necessary.

      Oracle didn't want to kill MySQL. They wanted to make it easier to sell potential customers on the transition.

      If your goal is to make money, it is an obvious path to take.

    57. Re:Rule #1 by Anonymous Coward · · Score: 0

      Ignorant bullshit. On very high load systems, Oracle can't carry MySQL water.

      MySQL is buggy, capricious and sometimes ugly, but it's not a "toy" database. For instance, Facebook (or Slashdot or Amazon or many others) couldn't work with Oracle but MySQL takes it without blinking. Based on previous experience I assume that the teams who manage them have to rebuild and tweak and maintain those servers constantly but at least it works.

      Amazon did try Oracle a long time ago and it shat itself. Look it up.

      Besides being obscenely overpriced and ridiculously dated in terms of features, Oracle just can't do high volume, even if you rewrite your whole stack to work with RAC.

      Learn a thing or two before coming here to spout your Oracle marketing.

    58. Re:Rule #1 by Anonymous Coward · · Score: 0

      Percentage of revenue coming from new customers has gone down every quarter for over 10 years at Oracle. They're basically just raping the same people over and over.

    59. Re:Rule #1 by rholtzjr · · Score: 1

      Java painful to use? How? What parts are painful?

    60. Re: Rule #1 by Anonymous Coward · · Score: 0

      It's not painful at all.

      This comment throws Exception, CommentException, PostedTooFastAsACException.

      The following 78 functions can be ignored, they're required to implement SlashdotCommentListener.

    61. Re: Rule #1 by Anonymous Coward · · Score: 0

      Maintainability. You'll have to hire 3 times as many devs when they have to spend all their time trying to figure out your 7 group by's, 12 joins, and a poorly indented WHERE clause with nested conditions that everyone is too afraid to change.

      Meanwhile, the competitor has a while loop and it's fine because it's only 12 items long.

    62. Re:Rule #1 by Anonymous Coward · · Score: 0

      He bought it mainly because of Java.

      It was (almost) all about the Java. Oracle tried to sell the hardware (and of course the related Solaris software) component off (to anyone?) when they were doing the Sun deal, but there were no takers, so (in typical marketing spin) they announced they always wanted it (because they could make Sparc great again). The other parts of Sun (mysql, virtualbox, staroffice, etc.) were all small parts of Sun (important to some, but small parts) that never really mattered over all in the deal.

      Arguably IBM would have been a better fit (organizationally, and corporate philosophy) than Oracle, but they passed on it. But is is highly likely that if IBM had done the deal, Sparc would have disappeared even quicker (Power was the answer. The question is irrelevant). Likely the same for the StorageTek tape libraries (IBM has their own solution).

    63. Re:Rule #1 by Anonymous Coward · · Score: 0

      Ignorant bullshit. On very high load systems, Oracle can't carry MySQL water.

      MySQL is buggy, capricious and sometimes ugly, but it's not a "toy" database. For instance, Facebook (or Slashdot or Amazon or many others) couldn't work with Oracle but MySQL takes it without blinking. Based on previous experience I assume that the teams who manage them have to rebuild and tweak and maintain those servers constantly but at least it works.

      Amazon did try Oracle a long time ago and it shat itself. Look it up.

      Besides being obscenely overpriced and ridiculously dated in terms of features, Oracle just can't do high volume, even if you rewrite your whole stack to work with RAC.

      Learn a thing or two before coming here to spout your Oracle marketing.

      ROTFLMAO.

      Good one.

      Nice troll. You had me going for a while. But your "Oracle just can't do high volume" was just a bit too far - it made your troll obvious to anyone with experience with real databases.

    64. Re:Rule #1 by hey! · · Score: 2

      I suspect the one thing which Oracle wanted from Sun was control of Java. Not necessarily for nefarious purposes (although a more ruthless company I have seldom encountered); it was just intolerable given the commitment they'd made to Java to have it in anyone else's hands.

      MySQL was a great project, but there is no way it threatens Oracle's database customer base.

      Oracle has an aggressive lock-in strategy for its database customers; to that end not only does it offer myriad proprietary ways of doing things, it offers some genuinely impressive technical capabilities; it also works hard to co-opt DBAs by having them acquire a number of Oracle-specific skills. This makes it both difficult and unattractive to move away from Oracle.

      One thing Oracle got into early was copy-on-write technology. This gave them far better transaction isolation than their competitors. It's even possible to create long-running forks of a databases, and then later merge those forks -- just like forking and merging a source code tree.

      Sure, as a backing store for your web site, pretty much anything will do the job. Oracle is overkill -- in fact relational databases in general are overkill.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    65. Re:Rule #1 by Skuld-Chan · · Score: 1

      I've actually seen a few of our line of business applications (Hyland Onbase as one example) migrate to Microsoft SQL simply because of arcane licensing from Oracle. I know this is heresy here, but MS-SQL actually performs better than Oracle and is cheaper, but of course some vendors require you run Oracle :(.

      On Oracle licensing - it's one of the few cluster of servers we have that has to be on physical machines because it was deemed cheaper.

    66. Re:Rule #1 by Ami+Ganguli · · Score: 1

      Business logic !== logic.

      You put logic into the data model that's tightly-coupled with the model. If this is code that must change when the data model changes, then it should live with the data model. It can then be re-used by different applications, and it helps isolate those applications from changes to the data model.

      The "re-use" bit is really key. If you have multiple applications, with different teams of developers, all accessing the same database, then you can assume that none of the application teams really understands the data model as well as the DBA does, and really they shouldn't need to. Stored procedures provide a higher-level abstraction, and protect the database from developers who might not know exactly what's going on with the data.

      --
      It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
    67. Re:Rule #1 by Anonymous Coward · · Score: 0

      Oracle marketing as I've seen it: Large electric power company puts together committee to pick 'standard' database, headed by non-technical political person.

      At the end of the process that person, more or less, single handedly picks Oracle. With plans to include apps once the database is fully embedded.

      Before the chaos can really start. The decision maker gets a new, no show, job, at about 6x salary. From (wait for it) Oracle marketing.

      That only goes on so long before even MBAs start to see. Oracle has been at it longer than anyone but IBM.

    68. Re: Rule #1 by Jherico · · Score: 1

      Yes, thank god we've all converged on the clean, easy to understand x86 / x86_64 architecture.

      --

      Jherico

      What can the average user can do to ensure his security? "Nothing, you're screwed"

    69. Re: Rule #1 by HornWumpus · · Score: 1

      You've obviously never had to implement 12 client side joins. Sure if you've got 12 joins to a single 100 row company table, no problem. But if each join is a server roundtrip for a lookup you've just fucked yourself with a ghost pepper.

      Bad code is a bad argument, unless you think the client side is somehow immune.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    70. Re:Rule #1 by Herkum01 · · Score: 1

      The issue I have with putting the business logic into database is that error handling is horrible. It will not give you anything useful about what went wrong.

      That is why everything has an intermediary layer or service for checking submissions and returning human readable information about what is missing or incorrect.

    71. Re:Rule #1 by HornWumpus · · Score: 1

      That just means they didn't understand MySQL. Its many idiosyncrasies lock you to it. Its users are commonly ignorant of anything better, or they wouldn't be using it.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    72. Re:Rule #1 by HornWumpus · · Score: 1

      MySQL is second only to Devnull for accepting bandwidth.

      It's problem is you aren't guaranteed anything like transactions when running it in that mode. Change MySQL's ISAM to something that supports transactions and the performance goes to shit.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    73. Re:Rule #1 by HornWumpus · · Score: 1

      BJs were for MBAs not engineers. So yes, bad thing.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    74. Re:Rule #1 by Anonymous Coward · · Score: 0

      > To kill MySql, which was a long term threat to Oracle's core business.

      Yeah that worked great. MySQL is indeed dying.

      MariaDB on the other hand....

    75. Re:Rule #1 by HornWumpus · · Score: 1

      Science moves forward, one funeral at a time.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    76. Re:Rule #1 by Anonymous Coward · · Score: 0

      Not just Postgres, but a lot of Oracle workloads can move to NoSQL data stores, or be managed by a Cloudera installation.

      Posting anonymously as the FTSE100 company I work for is also phasing out Oracle databases. They just aren't worth the licence cost and hassle.

    77. Re:Rule #1 by Cederic · · Score: 1

      Yeah, back then every single Oracle acquisition target was writing software in Java and the language was controlled by Sun and IBM.

      Oracle couldn't afford IBM.

    78. Re:Rule #1 by DuckDodgers · · Score: 1

      It's workable and high performance. But there are hundreds of posts showing how Scala, Kotlin, or Ceylon let you do everything that Java can do with 50%, 75%, sometimes 90% fewer lines of code without sacrificing readability. Even with lambdas in Java 8 and collection helpers in Java 9 (or 8? I can't remember), it lags the others in a huge way.

      Java has the most ceremony syntax of any popular language since COBOL.

      And yes before anyone says it, your IDE can fold code and auto-generate setters and getters and delegating constructors and so forth. But instead of putting class Person with its five fields and three constructors and five getter/setter pairs in its own file, you can have something like "case class Person(val name: String, val dob: Date, .....)" in one line and get all the rest for free inside another file and get right down to using Person objects.

    79. Re:Rule #1 by hey! · · Score: 1

      Oracle couldn't afford IBM.

      Thank the $deity.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    80. Re:Rule #1 by Cederic · · Score: 1

      You kidding? We could've killed them both off, all at once.

      Such a lost opportunity.. :(

    81. Re:Rule #1 by Anonymous Coward · · Score: 0

      MySQL is second only to Devnull for accepting bandwidth.

      It's problem is you aren't guaranteed anything like transactions when running it in that mode. Change MySQL's ISAM to something that supports transactions and the performance goes to shit.

      In other words, MySQL works well as a write-only data dump similar to /dev/null, but if you try to use it as a real database it sucks?

      WHO KNEW?!?!?!

    82. Re:Rule #1 by Doctor+Memory · · Score: 1

      I used an ERP that only gave requirements for Sun SPARC/Solaris with Oracle databases

      Let me guess -- Peoplesoft? (An Oracle company)

      --
      Just junk food for thought...
    83. Re:Rule #1 by mt2mb4me · · Score: 1

      We're sorry, this software is incompatible with your version of java because it is insecure. Here at the shop we have to keep some windows XP boxes around to run ancient versions of JAVA so some of the hardware management tools will still work.

    84. Re:Rule #1 by rholtzjr · · Score: 1

      If you are talking constraints put into the model that only allows certain data to be entered into the database, then I agree. That is called data integrity constraints, not necessarily "logic".

    85. Re:Rule #1 by rholtzjr · · Score: 1
      Soooo, it is painful that you chose hardware that was tethered to specific version of Java, and that is Java's fault? It seems that you chose the wrong hardware that became outdated with insecure management tools. That is not painful, that is poor choice.

      And IF the hardware company refuses to provide an updated software to run in an up to date version, that is what de-compilers are for.

    86. Re:Rule #1 by Anonymous Coward · · Score: 0

      >Another reason is that the database will usually be the longest living part of the software architecture.

      This is the key. People like to say "Don't do any logic on the database because you might change it" without considering that virtually no one ever actually does change the database. The layers sitting on top of it are almost universally the ones that get changed out and the database continues doing its thing. In 25 years, I have yet to see an RDBMS swapped out on any of my projects, but I've seen the other layers dumped with regularity.

    87. Re:Rule #1 by Anonymous Coward · · Score: 0

      Careful with that a-word, the furries might hear, and we'll end up with disturbing Ellison portraits on DeviantArt.

    88. Re: Rule #1 by Anonymous Coward · · Score: 0

      We are a legacy support company for things out of Enterprise support. We aren't hiring someone to decompile java. Java based management consoles are the only utilities that are a pain,. Ones that use HTML or C C++ .net etc all still work over the years. None the less. It is still a pain in the ass, workaround or not. Not to mention the generally slow, and shitty ui associated with java tools

    89. Re:Rule #1 by Anonymous Coward · · Score: 0

      One more: Sometimes the communication overhead of moving all data to the application server, process/aggregate it, and put the results back to the DB is just prohibitive. If you have the logic on the DB side, the data does not need to leave the DB server at all.

    90. Re:Rule #1 by rholtzjr · · Score: 1
      And I have had to work on said systems that have been around for 25+ years when the original "logic" was put in and now has no applications that specifically use it. This is the biggest argument to NEVER put logic into the database that are application specific. When the application is replaced, I have had to fight tooth and nail to get the logic out of the database and put it into a rules engine where it belongs. It's called the Las Vegas syndrome. What in the database, stays in the database.

      IMO, let a database do what a database is good at. Store/retrieve data in a reliable fashion. Once the database becomes the application, in most cases, the application will never be able to progress as the database has become the limiting factor.

    91. Re:Rule #1 by rholtzjr · · Score: 1

      To uniformly enforce rules when accommodating multiple applications accessing the same data.

      Data Integrity constraints, all for it.

      Another reason is that the database will usually be the longest living part of the software architecture.

      Absolutely, and when that logic now interferes with the application from progressing, you are now talking a total redesign. I have run into this multiple times. Put too much into the model, and the database becomes the bottleneck.

      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, it will, but that will depend on what the schema change entails. Anyway, ORM's have always been tightly coupled to the schema, in general, what applications aren't? The advantages of store procedures as I see it is only in the execution of mutli-table CRUD that is transactional (which will not even cover multi-homed heterogeneous data stores). That is it. If you rely heavily on stored procedures for anything else, you are asking for maintenance issues later on down the line, especially when you have multiple applications accessing the same database.

      So I will disagree with you on that putting business logic into the model is an acceptable choice.

    92. Re:Rule #1 by Dragon+Bait · · Score: 1

      Then why the fuck did he buy it?

      To sue Google over Java copyright violations?

    93. Re:Rule #1 by rholtzjr · · Score: 1

      It is not as uncommon as you think. I have already done this for a Government agency when Oracle upped their price list. They basically were told by an agency that deals with taxpayers money, that they will switch to a less expensive alternative if the price was raised. Well, that was 4 years ago. It was not that difficult to do so either.

    94. Re:Rule #1 by Anonymous Coward · · Score: 0

      every single application ever coded in it

    95. Re:Rule #1 by Anonymous Coward · · Score: 0

      All of them.

    96. Re: Rule #1 by rholtzjr · · Score: 1

      So, a self induced wound is painful. SHOCKING!

    97. Re:Rule #1 by Anonymous Coward · · Score: 0

      This is like saying "why is business logic in the soap api? it will not give you anything useful about what went wrong." The data interface is the data interface. If someone wants to create a bunch of stored procedures that just throw "something went wrong" exceptions, they're free to do so, and they often do. If someone wants to design a useful interface that can be consumed easily by multiple applications using database stored procedures with meaningful error conditions, they're free to do so. Believe it or not, sql engines usually (I take absolutely no responsibility for mysql) return pretty meaningful error messages especially around type problems, and things like unique indexes and foreign key relationships should absolutely be considered business logic and implemented in the database.

      I just had to spend three weeks dealing with a situation where someone thought it would be great to simply serialize all their data constructs in php and use mysql as pretty much a keystore. Guess how well stuff scales when you have to load everything into the application to make sure aggregates from the data deep in the serialization meet certain criteria (ie max four orders / week from this cost center). It seems that for the current generation, memory and hard disk space are supposed to be infinitesimal, speed never matters, and clients never come up with new requirements. Frigging locusts.

  3. Bryan Cantrill has this to say by Anonymous Coward · · Score: 0

    http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/

  4. RIP Solaris by Anonymous Coward · · Score: 0

    You won't be missed.

    1. Re:RIP Solaris by Anonymous Coward · · Score: 0

      I've had to work with Solaris in the naughties and I can but agree.

  5. Not surprising. by Anonymous Coward · · Score: 1

    I got rid of all my Sun gear shortly after Oracle bought them a few years back. I knew when they cut off support for legacy equipment that they were not going to save the platform.

    1. Re:Not surprising. by _merlin · · Score: 1

      It's been on life support for years. I knew it was coming when I saw the Blade 2500 tower in 2004, but I willingly went into denial. Since then it's just been a slow death spiral.

    2. Re:Not surprising. by Anonymous Coward · · Score: 0

      Ah, the days when security updates weren't shoved behind ridiculous support contracts.

      I miss my rack of x4600s. Louder than a fucking jet engine, and glorious, absolutely glorious.

  6. Probably by Anonymous Coward · · Score: 0

    Probably a bunch of old farts who think PLCs and SCADA are hot technologies. Today, they play a vital role in the workforce by keeping hideous old jerry rigged systems written in some sad old technology barely running so hives of middle managers can put off the inevitable complete rewrite for another quarter.

    1. Re:Probably by Anonymous Coward · · Score: 0

      Probably a bunch of old farts who think PLCs and SCADA are hot technologies. Today, they play a vital role in the workforce by keeping hideous old jerry rigged systems written in some sad old technology barely running so hives of middle managers can put off the inevitable complete rewrite for another quarter.

      I laughed at this. I work in an industrial facility using obsolete PLCs. Overlooking the obsolete PLCs are obsolete SCADA systems. Not running Solaris or SPARC, but running obsolete DEC PDP/11 and VAX. These are " hideous old jerry rigged systems written in some sad old technology barely running". The biggest improvement we've had is buying several $20,000 CHARON licences that let us emulate these systems on commodity desktop PCs. We also have "new" stuff running on DEC Alphas that aren't a concern yet because they aren't beyond obsolete yet.

  7. What could Oracle have done differently? by EzInKy · · Score: 1

    Maybe be a bit more Linux friendly? Hope they don't go the way of SCO. In the meantime, Redhat keeps chugging along.

    --
    Time is what keeps everything from happening all at once.
    1. Re:What could Oracle have done differently? by Narcocide · · Score: 1

      Opening the hardware, or at least making it cost-effective might have gone a long way.

    2. Re:What could Oracle have done differently? by EzInKy · · Score: 1

      So moving to Win/Win philosophy might save the company?

      --
      Time is what keeps everything from happening all at once.
    3. Re:What could Oracle have done differently? by cheesybagel · · Score: 1

      SPARC *is* open and Fujitsu (formerly HAL) also designs high-end SPARC processors. There are several vendors of low end SPARC systems for space and military applications. Heck even the Russians have a SPARC CPU clone.

    4. Re:What could Oracle have done differently? by gl4ss · · Score: 1

      making the whole thing cost effective would have gone a long way. because then it would have been good business.

      --
      world was created 5 seconds before this post as it is.
    5. Re:What could Oracle have done differently? by TheRaven64 · · Score: 1

      They open sourced the verilog for the T1, but very few people did anything with it. There's a cut-down FPGA version that a few people use for teaching, but that's about it. I wouldn't be too surprised at this point if Oracle became an ARM licensee. The interesting things on their recent SPARC processors have been database and crypto offload engines, not the CPU cores, and this would let them outsource the cost of CPU, toolchain, and OS development.

      --
      I am TheRaven on Soylent News
    6. Re:What could Oracle have done differently? by Anonymous Coward · · Score: 0

      wonder what Fujitsu is going to do now, since those servers run Solaris.

      they could run Linux, but why.

  8. VirtualBox by that+this+is+not+und · · Score: 4, Interesting

    Has there been any word about VirtualBox? That is pretty much the only former-Sun softwarevI use on a regular basis. Since the Oracle purchase of Sun I have wondered why Oracle was keeping it alive.

    1. Re:VirtualBox by antdude · · Score: 1

      I hope they don't kill it. I love it. I do remember they were still hiring and updating.

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    2. Re:VirtualBox by Tailhook · · Score: 5, Interesting

      VirtualBox is difficult to explain. Oracle has never seriously tried to monetize it. They've never inflicted a Java installer on VirtualBox users. Most of it is still Open Source and they haven't driven off the entire user base to some fork. They haven't done any of the damage this sociopath or a corporation does to everything else they acquire.

      I pointed this out to a moderately clever person once. He suggested that perhaps Oracle forgot about it. Maybe there is a small team of dedicated developers quietly enhancing their work, filling out their TPS reports and successfully avoiding notice.

      --
      Maw! Fire up the karma burner!
    3. Re:VirtualBox by Anonymous Coward · · Score: 0

      probably because it has no real marketshare now or any potential of ever gaining any given the competition in this space. Probably better to leave it as is as should the market change at least they have something to fall back on.

    4. Re:VirtualBox by Bing+Tsher+E · · Score: 2

      I used wget to grab the whole set of the current version installers. You can never be too safe.

    5. Re:VirtualBox by antdude · · Score: 1

      Good idea. Another problems are fixes and updates with newer stuff. :(

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    6. Re:VirtualBox by whoever57 · · Score: 2

      So you are saying that the VirtualBox team are the equivalent of Milton Waddams?

      Just hope that Oracle doesn't bring in "the Bobs".

      --
      The real "Libtards" are the Libertarians!
    7. Re: VirtualBox by Anonymous Coward · · Score: 0

      The installers of the source code? Get the latest source code which is I think 5.2 Beta.

    8. Re: Virtualbox by that+this+is+not+und · · Score: 1

      I looked on the VirtualBox website and it says that it's licensed under GPL v.2. Still, the source does need to be secured.

    9. Re:VirtualBox by TheRaven64 · · Score: 2

      Sun's goal for VirtualBox as to make it a gateway drug for their Xen + Solaris + proprietary management tools stack. The idea was that VirtualBox would make it easy to create small numbers of VMs for managing infrastructure, but when you got to a larger scale you'd want to buy the bigger system. Now that Oracle has started dabbling in the cloud provider space, they may start caring again for the same reason.

      --
      I am TheRaven on Soylent News
    10. Re: VirtualBox by that+this+is+not+und · · Score: 1

      The source code is nice if you have the whole toolchain up and running to build from it. But they disyribute a Windows and MacOS binary installer, and a whole bunch of linux binary installers for a lot of different linux variants. VirtualBox is something a lot of people 'just use' to run virtual OS instances, particularly to run binaries on those OSes that they probably don't have on the systems hosting the VMs.

      Sad to say, because at root everything is supposed to start out as source code, but sometimes it's binaries all the way down.

    11. Re:VirtualBox by drinkypoo · · Score: 1

      The idea was that VirtualBox would make it easy to create small numbers of VMs for managing infrastructure,

      Too bad it never did. KVM took over that job. VirtualBox makes it easy to create one or two VMs, but you don't really want to get into more than that.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    12. Re:VirtualBox by Anonymous Coward · · Score: 0

      My supposition has always been that they are being paid by the NSA to maintain VirtualBox.

    13. Re:VirtualBox by Anonymous Coward · · Score: 0

      I used to do VirtualBox headless with 5-6 VMs on a dual core 8GB system quite nicely. It can do way more than people think.

      About 8-10 years ago, they demo'd live migration (teleporting) from a MacOSX host to a Windows host. I think they can do amd/intel also.

      The only times I've preferred VMware workstation were to virtualize a vSphere/ESXi system to test bare metal backups and whenever my system gets rebooted and there are VMs running. They get corrupted :-( I'd love to have a solution for either.

    14. Re:VirtualBox by Anonymous Coward · · Score: 0

      Virtualbox exists, in Oracle's eyes, because it is (realistically) the only desktop VM that supports Solaris.

      VMware's desktop products are pretty much abandoned and have never properly supported Solaris. Oracle fancies themself a "solution provider" and they seem VMware a competitor. They're not going to pay VMware to support a niche product.

      VirtualBox is an independent team and Oracle pays their bills. In turn, VirtualBox supports Solaris so developers can have a dev environment. Because fucking NOBODY runs solaris on workstation. Or even with a GUI.

      I've got a hunch that the Virtualbox team said these would be the terms (That is the open source project would continue) or they'd take their talent elsewhere. Without Virtualbox there is no Solaris development, so Virtualbox continues.

    15. Re:VirtualBox by Anonymous Coward · · Score: 0

      I used a download manager with a GUI to grab a whole set of installers for another program. Why specifically mention wget as if you're a supernerd?

  9. One Rich A**hole Called Larry Ellison by Neo-Rio-101 · · Score: 1

    Need to bring that acronym back out again.

    Sayonara YachtOS

    --
    READY.
    PRINT ""+-0
  10. Tech industry observer by Anonymous Coward · · Score: 0

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

    Is this the same Simon Phipps who was Chief Open Source Officer at Sun, who resigned when Oracle bought them out? In this context, he's a bit more than just a "tech industry observer".

    1. Re:Tech industry observer by jaklode · · Score: 0

      true

  11. Virtualbox by Anonymous Coward · · Score: 0

    Is virtualbox safe? Somebody make sure they have all the open source code to that in case Oracle decides to whack it.

  12. More information the Layoff by plopez · · Score: 3, Informative

    In case anyone wants more insider info. https://www.thelayoff.com/orac...

    --
    putting the 'B' in LGBTQ+
  13. Cue assholes here saying... by Anonymous Coward · · Score: 0

    "Solaris was dead a long time ago!" And "Solaris was still being developed?", etc. fuck you all.

  14. A problem of Sun's making. by upuv · · Score: 5, Insightful

    Lets face it Sun made mistakes. These mistakes made it ripe for take over and plundering by Oracle.

    The biggest mistake was Linux. When Red Hat launched no one took it seriously. Red Hat legitimised Linux in the eyes of industry. Companies faced with massive expansions of internet equipment simply could not afford the iron from SUN / HP / IBM. These small start ups went to Linux. One such startup was Google. All of a sudden massive new companies emerged on a platform that was not enterprise iron. Overnight Dell become a major player in the server room.

    What did Sun do about this? Nothing. Even when faced with new unit sales that were almost zero compared to just a few years before sun still did nothing. Sun released Solaris for x86/64. But completely forgot to get 3rdparty shops and it's on internal application development teams to port to it. They only thing that ran on the x86/64 Solaris was open source software. Stuff that was already running on much cheaper x86/64 gear. Sun limped on for a few years making the occasional uplift sale for existing gear in the field.

    Then Oracle pounced. Suns mistakes led to this point. They sold for far less than they were worth. Why? The market lost all faith in Sun's ability to generate a cash flow. Thus the negative impact on asset value.

    Oracle saw something it liked very much. Java. Oracle instantly went on a predatory path of trying to extract money out of Java. We all know how well that went. Oracle just recently announced that they are looking to open source the Java EE specification. This predatory cash grab caused some other interesting market changes. The explosion of new languages resulted and they got market share. Ruby on rails in my opinion would have never had as much success as it once did with out Oracles legal threats over java usage.

    Oracle also needed to save it's DB division. At that point Oracle DB pretty much was only ever deployed on pricey Sun gear. Also Sun owned the control of MySQL. Which was growing at an astonishing speed. This threat needed to be squashed at all costs. In my mind these were the real reasons for Oracles purchase of Sun.

    There were some other assets that Oracle was looking to sell off. But in the end Oracles taint reduced their value to zero. OpenOffice comes to mind.

    I still remember the day when Oracle purchased Sun. There was an audible groan in the office. Execs around the world were scrambling to find alternatives to many products. Sun certified engineers instantly saw there pricey certificates devalue in an instant.

    The only reasons Oracle has kept Solaris and SPARC alive for so long are:
    1. Uplift purchases still come in. But not many. These can be counted in 1000's world wide. Basically nothing.
    2. The platform became part of the Exadata/Exalogic platform. ( An an holy creation in my mind. )

    1. Re:A problem of Sun's making. by whoever57 · · Score: 5, Insightful

      The biggest mistake was Linux. When Red Hat launched no one took it seriously. Red Hat legitimised Linux in the eyes of industry.

      I disagree. The root problem was that single-thread performance of Sparc lagged Intel x86 around the time the PIII came out. Linux made adoption of x86 possible for many applications, but few of them would have moved to x86 without the big performance and cost benefits of adopting it.

      Sun tried to compensate with more cores, but that only made Sparc more expensive and many applications were not written to take advantage of multi-core hardware.

      --
      The real "Libtards" are the Libertarians!
    2. Re:A problem of Sun's making. by Anonymous Coward · · Score: 1

      Sun's issue was not a software one, it was the inability to compete with commodity hardware. At their core they were very much a hardware focused company and that was moribund when oracle stepped in. The writing was on the wall for Sun long before the end came and the smart ones had already jumped off their kit or were migrating away.

    3. Re:A problem of Sun's making. by Anonymous Coward · · Score: 0

      Sun certified engineers instantly saw there pricey certificates devalue in an instant.

      Nonsense! I still recall fondly those two weeks I spent holed up in that hotel in downtown San Francisco while attending their classes. Love that city!

    4. Re:A problem of Sun's making. by bungo · · Score: 5, Informative

      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
    5. Re:A problem of Sun's making. by Anonymous Coward · · Score: 1

      > But completely forgot to get 3rdparty shops and it's on internal application development teams to port to it.

      "its"

    6. Re:A problem of Sun's making. by TheRaven64 · · Score: 1

      The root problem was that single-thread performance of Sparc lagged Intel x86 around the time the PIII came out

      Depends a bit on the SPARC, but the real problem was lack of volume. You could still buy faster SPARCs around that time, but they cost an order of magnitude more for a 10-20% performance improvement. If 20% means a lot to you, then you're going to start looking seriously at SMP and often a little bit of refactoring could buy you a 20+% improvement with a dual-processor system, which cost only a little bit more than double the price of the single-processor system.

      --
      I am TheRaven on Soylent News
    7. Re:A problem of Sun's making. by _merlin · · Score: 4, Insightful

      I see it differently. MS killed desktop UNIX by being good enough. Desktop UNIX was better, but Windows NT 4 on commodity hardware was (perhaps just barely) good enough, and far cheaper. This impacted all the UNIX vendors, as it killed off a significant revenue stream.

      Sun was losing the performance battle badly with SPARC. This was painfully obvious with the Sun Blade 2500 tower. The CPUs were no faster than the Blade 2000, and it had a quarter of the RAM bandwidth as a cost-saving measure (they reduced memory from 256 bits wide to 64 bits wide so you could install RAM DIMMs individually rather than in groups of four). They were still trying to charge premium prices for SPARC, but x86 and POWER were walking all over it in performance. They managed to score some wins on highly-parallel workloads with the UltraSPARC T series (Niagara), but it was always specialised and Suns AMD64 boxes performed better on most workloads.

      Sun was spread far too thin on the ground and faced with falling revenues. They tried open source as a strategy, but open sourcing something provides no value on its own. They couldn't maintain/enhance their OS (Solaris), compilers (SunPro), Java, and everything else. They were floundering, occasionally coming out with an interesting product, but no consistency.

      Ruby on Rails was framework-of-the-month already by 2006, years before the Oracle purchase. The explosion of programming languages would've happened anyway, it's a result of all the people who studied computer science after the first dotcom bubble. J2EE had already been co-opted by Apache and Red Hat, and let's face it, hardly anyone even uses J2EE. Most of the time Spring is a lighter-weight substitute, you only really want J2EE if you need distributed transactional consistency.

      Sun were lucky to sell out when they did. They really didn't have a viable plan, and taking the money and running probably was the best thing for the shareholders. They'd already open-sourced most of the stuff that had any value, so it wasn't going to matter too much how Oracle mismanaged it. Oracle were stupid to buy Sun, as it was already pretty obvious there wasn't really much worth buying.

      Yeah, I miss Sun, but the Sun I miss had already faded long before the Oracle purchase. I just didn't want to believe it and willingly went into denial.

    8. Re:A problem of Sun's making. by upuv · · Score: 1

      Oracle did not buy tech from Sun hardware or software.

      Oracle bought customers and revenue streams. Or the potential for revenue streams in some cases.

      Oracle knows that it can not keep support more and more software and hardware platforms. Oracle never mismanaged anything internally. They would have never intended to a lot of it going past the 2,5,10 year marks for various tech. They did mismanage or failed to anticipate market and client reaction. Case in point the Java non-sense where they tried to claw money, big money out of old sun clients that had no obligation to pay.

      As for some of Sun's mistakes.
      The open source strategy was broken. Several reasons. They pushed the SPARC arch above all else. They kept tools required to build advanced product proprietary. Their community portals were horrible. Solaris had a broken patching/package system. ( God that was awful ) They simply did not adapt/adopt fast enough to be part of the Opensource world. yum and apt were light years ahead. They completely underestimated the power of creating a professional services unit that would actually be competent with opensource tools.

      You are right though. The Oracle buy was the best deal they would ever see.

    9. Re:A problem of Sun's making. by Zontar_Thing_From_Ve · · Score: 1

      I agree that Sun made mistakes, but I see 2 major mistakes that you overlooked in your otherwise fine post.

      1) I don't have the numbers to back this up, but the internet bubble had to have had a catastrophic effect on their finances. Almost all of those startups that went bust were using Sun equipment and there is no way that equipment was fully paid for by the time those companies went bust. What looked like a huge sales win for Sun suddenly rebounded on them when the market got flooded with excess equipment that wasn't fully paid for.
      2) The change in the early 2000s to really cheap Intel/AMD CPU hardware running Linux was completely unanticipated by Sun and they had to scramble after the fact to make something for this market. HP and IBM looked bad in the internet bubble because nobody wanted their stuff, but they rebounded big time when businesses switched to commodity hardware running Linux because they had the ability to make those kinds of machines. Sun lost tons of sales and by the time they competed in that market with their own offerings, the lost business didn't come back.

    10. Re:A problem of Sun's making. by that+this+is+not+und · · Score: 1

      You could get Solaris almost for free. Especially if not for commercial use. However, a C compiler to actually do much at all with Solaris was quite expensive.

      You could use GCC, but if you're going to do that, why not just use Linux?

    11. Re:A problem of Sun's making. by Anonymous Coward · · Score: 0

      I appreciate your points but some is not accurate. By the time Oracle bought Sun, even large conservative organisations were moving from Sun platforms to cheap Linux machines. Oracle were very comfortable in this area already so this was not to save the Oracle DB, at least not to deal with it in terms of which platform it was run on.

      The main reason was java as people have pointed out. The secondary items would have been sparc as solaris was more or less open by this time,. Java is an important element of Oracles software line up. There's a java machine inside the database. Not only that, enterprise manager makes good use of java as do oracles client side development s/w. When it came on the market, they did the right thing in deciding to want to control it as much as possible.

      With respect to Oracle tainting Java, again I think you've got your timelines wrong. Ruby and Ruby on rails were already well established by the time Oracle acquired java.

      I don't quite understand your comments regarding exadata. To be fair I don't know a lot about exalogic but with exadata Oracle are one of the few companies outside of super-computing that are keeping big-iron alive. To be fair, most exadata machines are intel based but they are sophisticated database running machines designed in every practical respect to run the database as quickly as possible. Large amounts of flash storage, very fast internal IO, massive amounts of data and intelligent IO all make them very effective.

    12. Re:A problem of Sun's making. by _merlin · · Score: 1

      Solaris zones, and cluster-like features on Sun hardware (e.g. being able to take bad RAM out of service without bringing down the OS). They did have some cool technology, Linux on commodity hardware still doesn't have a viable replacement for either of these features.

    13. Re:A problem of Sun's making. by whoever57 · · Score: 1

      I don't recall when this happened, but my (small) company was looking at buying another machine to run simulations.

      One manager wanted to buy Sun, but I was sceptical.

      We benchmarked the Sun machines against an x86 (PIII, I think) and the x86 was twice as fast (for half the cost). Note that we were running a single-threaded closed source application (ModelSim, I think).

      Price/performance wise the x86 machine was 4 times better than Sun. We could not refactor and the difference was so compelling that we never bought another Sun machine.

      --
      The real "Libtards" are the Libertarians!
    14. Re:A problem of Sun's making. by ebvwfbw · · Score: 1

      IMHO, they made the same mistake SGI made. I tried to save SGI, they wouldn't hear me as a customer. Loved them in the 1990s. Just think about it a minute, I had a SGI Indy on my desk, camera on top, conference software and such and this was all in the mid 1990s. Back when the disk was 1G and it had 16 meg of memory. Then even something like ping became a chore to compile and perl was just about impossible. Standard stuff like that. They didn't care. Ok, I didn't care about SGI.

      Fast forward some years and I saw SUN doing the same thing. Fuck me attitude. Again I said - ok, see ya and moved it all over to RedHat Linux. Here we are.

      Same conversation with Suse and their what I think is best described as a hostile customer support policy. Even though we had a contract with them.

      I'm having this SAME conversation with RedHat. They used to be awesome. Now things like their Satellite while it's awesome when it works, it can break easily. Update anything and your whole satellite, ansible and so on could break for days, weeks, more unless you have a guru to fix it. They don't seem to care about other things either. I usually get - not our product, sorry.

      RedHat - are you listening? No, of course not. Probably the same guys that ruined other companies work for them now.

  15. Non-x86 Architectures by 0100010001010011 · · Score: 1

    So what did IBM do different with their POWER machines? Someone must be buying them because they keep on making them.

    1. Re:Non-x86 Architectures by Anonymous Coward · · Score: 0

      I have a feeling that POWER/AIX will suffer the same fate as SPARC/Solaris. IBM is pushing Linux on POWER quite hard. It's an uphill battle though. Even though P8 is reasonably priced, people are still rightfully wary of IBM lock-in, plus there's just that fucked up IBM way of doing everything that comes off as obtuse to anyone coming from, well, anywhere else.

      I foresee upcoming POWER releases as just another target for old LPAR consolidation until the apps that run on those systems can be retired or replatformed.

    2. Re:Non-x86 Architectures by Anonymous Coward · · Score: 0

      IBM uses their chips for multiple platforms. There is no case for SPARC other than having a platform to test big-endian code (Power Linux is little-endian unfortunately). If they are making AS/400 systems with their newest Power chips it's easy to make AIX and Linux systems too.

    3. Re:Non-x86 Architectures by jaklode · · Score: 1

      Linux platforms on Power(PC) traditionally are big endian. The introduction of little-endian into mainstream distributions is a fairly recent one.

    4. Re:Non-x86 Architectures by TheRaven64 · · Score: 1

      A few things things. The first is that they always had a larger market than SPARC, so their economies of scale were a bit better. The second is the HPC market. IBM doesn't put many PowerPC chips in supercomputers, but they charge a lot for the ones that they do, which helps offset R&D costs. Third, a lot of game consoles used PowerPC chips. These weren't the same designs as the high-end POWER systems (since POWER3, POWER implements the PowerPC spec and is just a marketing term for the expensive PowerPC systems), but they often shared some of the same pipelines and so could split the cost. They also consolidated their Z-series and PowerPC teams. Z-series is a fairly extreme CISC architecture, so is pretty different from PowerPC, but they now both use the same FPU designs (including hardware binary-coded decimal and a few other weird and wonderful things). This, again, reduces their costs.

      The other big difference is that IBM kept evolving PowerPC. SPARCv9 is still a clean RISC architecture that would be recognisable to the RISC II team at Berkeley in the '80s. It's not great as a modern compiler target.

      --
      I am TheRaven on Soylent News
    5. Re:Non-x86 Architectures by upuv · · Score: 1

      I foresee upcoming POWER releases as just another target for old LPAR consolidation until the apps that run on those systems can be retired or replatformed.

      Ah good old LPAR. This was probably one of IBM's biggest successes. It allowed them to sell a lot of hardware. You basically had to massively over provision in order to use LPAR's. It also had a great security story in the sales pitch. They managed to replicate their success of statically allocated disk space on mainframes to statically allocating all other resources on the host as well.

      LPAR's have for most application needs have been met by virtual machines. As the security/trust of VM's improved over the years so did their adoption stealing from LPAR's market. Now we are seeing the push of containers. Containers have a LONG way to go before they can be trusted. They also have to solve some nasty issues with networking and storage. A lot of issues actually.

      AIX will limp on for at least 15 more years. The big reason is there are shops out there that simply are unable to migrate. Gov/Mil/Bank sectors will keep it alive for a long time. Hell they are currently keeping it alive.

      The real issue is the death of the physical architecture. With x86 architecture becoming so powerful and low power and price points it's increasingly difficult justifying the purchase of outdated chips. Emulation now often outperforms actual physical chips.

      Looking at recent massive threaded chips from intel and amd it's really hard to justify these old architectures. I can buy and i9 from intel for home server use that blows the doors off of anything in the office server room. And I can emulate basically any other chip on it. Same goes for amd's thread ripper.

    6. Re:Non-x86 Architectures by Anonymous Coward · · Score: 0

      So what did IBM do different with their POWER machines? Someone must be buying them because they keep on making them.

      Kept investing in it, so performance didn't get stuck in the 1990s.

      MyLittlePony killed SPARC investment, and with it Sun Microsystems.

  16. Only real question is by oldgraybeard · · Score: 4, Insightful

    Why did they wait so long. We all knew this was going to happen. Oracle wanted the intellectual property not the actual projects or the people.

    1. Re:Only real question is by upuv · · Score: 3, Interesting

      The big reason they waited so long was they wanted/needed to migrate existing customers onto exa or cloud platforms. If they just killed it quickly they would effectively be loosing those customers, probably forever.

      Also OracleDB was one of the only reasons to buy SPARC anymore. Database shops hate platform change in general. No one ever got fired for buying SPARC for the DB environment.

    2. Re:Only real question is by oldgraybeard · · Score: 0

      Valid point!

  17. sorry, not sorry by greglarious · · Score: 1

    Having spent years struggling with Solaris instability for java (see madness linking required kernel patches to JVM upgrades) I honestly cant think of a single aspect of it that I miss. Regarding SPARC, I remember the JavaOne conference where Intel engineers sat side-by-side with Sun JVM engineers to describe their partnership to delivery the best Java performance ever. I also remember switching a specific Java application from SPARC to Intel with no other changes and seeing at 23x performance boost while lowering hardware costs. Not missing a single thing about SPARC either. Perhaps my experience was a fluke. Are there many people out there productive and stable using SPARC and Solaris? I had always assumed the entire market segment was maintaining legacy systems in situations where there was no money to move forward with modern choices.

    1. Re:sorry, not sorry by upuv · · Score: 3, Interesting

      In the early days SPARC was one of the only platforms that you could run x64 Java. Linux x64 was considered unstable and untested at the time.

      So we bought massive SPARC boxes to host java apps. A lot of java apps at once. And yes the performance was garbage. A dedicated engineer at least just constantly on the lookout for performance issues.

      I still remember one team going OK we built those new linux boxes for you. Only to find out they built them with 32bit linux. They simply would not build them x64. I had to remind them that the whole point of the project was to evaluate java on x64 intel. When they finally did rebuild them properly the initial performance tests were amazing. That company never looked back after that point.

    2. Re: sorry, not sorry by Anonymous Coward · · Score: 0

      In the early days SPARC was one of the only platforms that you could run x64 Java.

      Why would you want that? Isn't the point of Java that you can use the native runtime environment on any platform with a platform-independent bytecode application?

    3. Re:sorry, not sorry by Fallen+Kell · · Score: 1

      Solaris+SPARC still one of the best NFS fileservers on the market. Hard to beat 256 threads in a 3U box for handling I/O requests.

      --
      We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
    4. Re: sorry, not sorry by Dog-Cow · · Score: 1

      The only reason I can think of is memory. 32bit machines are limited (in practice) to 4GB address space, and quite a bit less than that for actual physical memory.

    5. Re:sorry, not sorry by Anonymous Coward · · Score: 2, Interesting

      Having spent years struggling with Solaris instability for java (see madness linking required kernel patches to JVM upgrades) I honestly cant think of a single aspect of it that I miss.

      Regarding SPARC, I remember the JavaOne conference where Intel engineers sat side-by-side with Sun JVM engineers to describe their partnership to delivery the best Java performance ever. I also remember switching a specific Java application from SPARC to Intel with no other changes and seeing at 23x performance boost while lowering hardware costs. Not missing a single thing about SPARC either.

      Perhaps my experience was a fluke. Are there many people out there productive and stable using SPARC and Solaris? I had always assumed the entire market segment was maintaining legacy systems in situations where there was no money to move forward with modern choices.

      Solaris and instability in the same post?

      YOU SIMPLY DON'T KNOW WHAT YOU'RE TALKING ABOUT

      Period.

      You don't.

      Call me when Linux actually implements AUTH_SYS properly instead of randomly grabbing the first 16 groups it finds. Yeah, that asinine, random, now-you-can-access-your-files-now-you-can't works really well in a large enterprise environment with tens of thousands of users.

      Call me when Linux fixes pwrite() - read the Linux man page, that bug has been in there for years and prevents access to a file that allows both atomic appends or atomically writes to any location.

      Call me when GNU stops trying to get POSIX to remove fork() from the list of functions required to be async-signal-safe - the glibc fork() implementation is broken and not async-signal-safe because the glibc developers STUPIDLY used pthread_atfork() handlers in glibc, of all fucking places. So instead of fixing glibc, GNU is pushing for lower standards.

    6. Re:sorry, not sorry by Anonymous Coward · · Score: 0

      In the early days SPARC was one of the only platforms that you could run x64 Java. Linux x64 was considered unstable and untested at the time.

      So we bought massive SPARC boxes to host java apps. A lot of java apps at once. And yes the performance was garbage. A dedicated engineer at least just constantly on the lookout for performance issues.

      I still remember one team going OK we built those new linux boxes for you. Only to find out they built them with 32bit linux. They simply would not build them x64. I had to remind them that the whole point of the project was to evaluate java on x64 intel. When they finally did rebuild them properly the initial performance tests were amazing. That company never looked back after that point.

      SPARC used to be fast.

      Then MyLittlePony drove Sun into the ground. He stopped investing in Sun's future, among other things tossing SPARC hardware development overboard in his monthly "reorganizations" used to hide layoffs.

      So SPARC performance pretty much got stuck in 2001 or so.

    7. Re:sorry, not sorry by TheRaven64 · · Score: 1

      And yet if you buy an off-the-shelf filer from NetApp or EMC it will be x86 hardware running FreeBSD. It turns out that you can beat 256 threads all playing cache-line ping-pong with fewer faster hardware threads that let your software threads share L1 cache.

      --
      I am TheRaven on Soylent News
    8. Re:sorry, not sorry by drinkypoo · · Score: 1

      Having spent years struggling with Solaris instability for java (see madness linking required kernel patches to JVM upgrades) I honestly cant think of a single aspect of it that I miss.

      The Sun stuff I miss is pre-Solaris, and it was a product of its age and is meaningless now. Early (68k) Sun hardware was awesome compared to almost everyone else's early hardware. Of course, it was also awesomely expensive, and awesomely power-hungry, but anyway.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re: sorry, not sorry by upuv · · Score: 1

      That's exactly the reason.

      Memory hogging java apps. Especially those that had to support lots of user sessions.

      Generally you try to avoid heaps this big as garbage collection will kill the app. But sometimes you have to. Also with off heap memory methods now heaps can become enormous. We are talking Tbytes in size. I even know of a Pbyte implementation of offheap memory.

    10. Re: sorry, not sorry by Anonymous Coward · · Score: 0

      But then using 64-bit SPARC Java would also solve the problem, right?

    11. Re: sorry, not sorry by Wootery · · Score: 1

      You're right that's meant to be part of the point of Java as a development platform, but there are also other reasons to use Java.

      It scales well, it does a reasonable job helping out on correctness and security, there's no shortage of Java developers, there's no real chance the platform will die overnight, and there's the No-one ever got fired for choosing Java effect.

    12. Re:sorry, not sorry by Anonymous Coward · · Score: 0

      x64 didn't exist in the early days of SPARC.

    13. Re:sorry, not sorry by atrimtab · · Score: 1

      I remember SunOS on the Sun386i. It was the first usable x86 based GUI (Sunview) or X Window system way back in 1988 that ran DOS and later Windows 3.x in virtual windows. Back then there was no usable MS Windows or SPARC yet.

      When Sun announced SPARC in 1989 and put all their "wood behind a one arrowhead" with Solaris 2 we moved on. Solaris 2 was real POS for the first 7 years.

      By the mid-90s there were the various BSDs and stable Linux. It was cheaper/faster/better to use x86 hardware except for corner cases particularly if you where running 7/24 services on the Internet. It was also a lot easier for knowledgeable people to use Open Source and fix it themselves than cry to a vendor in the middle of the night and HOPE they could provide a timely fix. They usually could not.

      Once AMD 64-bit x86 chips were available there was no need for SPARC or Solaris for general use cases unless you were locked into the Sun or Oracle ecosystems.

      After the Dotcom crash Sun was the walking dead because management couldn't figure out how to re-invent it without pissing off existing locked in customers and thus killing off their existing revenue streams even faster. So they tried a lot of half measures that did little to obtain new hardware customers while old ones slowly migrated away.

      --
      Facebook is billions of individual "Skinner Boxes." And if you use it you are the pigeon!
    14. Re:sorry, not sorry by PCM2 · · Score: 1

      It was the first usable x86 based GUI (Sunview) or X Window system way back in 1988 that ran DOS and later Windows 3.x in virtual windows. Back then there was no usable MS Windows or SPARC yet.

      Oh, I'm not so sure. I seem to remember running DESQview on ordinary PC-XT hardware earlier than that. Not exactly GUI like we're used to today, but pretty close. It could run text-based and graphical MS-DOS applications side by side.

      --
      Breakfast served all day!
    15. Re:sorry, not sorry by atrimtab · · Score: 1

      DESQView was pretty crude compared to 1988 Sunview and definitely X11 visually. Also the Sun386i could run CAD/CAM and other graphical DOS programs on the full 19" CRT at resolutions about 4x of a PC of the time.

      DOS CAD/CAM software cost about 15% of "real Workstation" versions back then, so that was a definite plus.

      They also made great trader workstations.
       

      --
      Facebook is billions of individual "Skinner Boxes." And if you use it you are the pigeon!
  18. You should only say nice things about the dead by Anonymous Coward · · Score: 0

    Solaris is dead. That's nice.

  19. RIF is not "Oracle-speak" by 93+Escort+Wagon · · Score: 1
    --
    #DeleteChrome
    1. Re:RIF is not "Oracle-speak" by Anonymous Coward · · Score: 0

      It's common Corporate-Speak.

      So is "made redundant" (from the summary)

      Normal people say they got laid off or fired.

  20. So, what's left? by Anonymous Coward · · Score: 0

    I'm trying to think of what proprietary UNIX systems still exist. AIX? Is HP-UX still a thing?

    1. Re:So, what's left? by Neo-Rio-101 · · Score: 1

      Yes, some companies still exist that use HP-UX on Superdomes.
      Why? Because the owners of these companies that run HP-UX strongly believe that free software is junk.

      --
      READY.
      PRINT ""+-0
    2. Re:So, what's left? by _merlin · · Score: 1

      As far as I know, AIX and macOS are the only actively-developed certified commercial UNIX operating systems left.

    3. Re:So, what's left? by TheRaven64 · · Score: 1

      I was going to reply saying that macOS hadn't been certified since 10.6, because Apple said that they'd no longer bother after that, but apparently I was wrong and 10.12 is certified (though apparently only UNIX03, which is a bit surprising because I've not found anything from UNIX08 missing and many of the UNIX08 additions were originally in macOS). The most interesting one on the list is Huawei EulerOS 2.0 - as far as I know this is the first Linux distribution to be certified UNIX.

      --
      I am TheRaven on Soylent News
    4. Re: So, what's left? by that+this+is+not+und · · Score: 0

      You mean, they pay the Open Group to use the trademark? I have purchased a few of their license plates myself, so I guess I have a "real" UNIX, too.

      Nothing that special, but Apple likes stuff like that.

  21. So who is Oracle going to buy now? by upuv · · Score: 1

    Obviously Oracle is clearing the decks to make room for something. The cash bleeders in the company are being sold off or shut down.

    This leaves some big holes in Oracle. Things that helped prop it's DB business are now basically gone. Oracle has publicly gone all in with the cloud. Privately I think they have other plans.

    So who is Oracle going to try and buy? Is it Red Hat?
    RHT 19.07B
    ORCL 209.399B

    They could do it easily. They could buy control for 10B.

    Or would they go after a global cloud provider? Like Digital Ocean?

    1. Re:So who is Oracle going to buy now? by Neo-Rio-101 · · Score: 1

      Not such a crazy idea for Oracle to take over RedHat. Oracle still have a presence in defence. RedHat gets most of it's funding from defence - from what I understand.

      Oracle has tried to steal RedHat's support lunch money for a long time, primarily by ripping off RedHat Enterprise Linux and only releasing supporting software for their database apps by ensuring that the packages only exist in the world of Oracle Linux and it's custom "unbreakable" kernel.

      It would be nice if Oracle then decided to open source Solaris since they're not going to develop it any more.... but knowing Oracle, it won't happen. I'm guessing they'll let the Solaris code and Solaris ZFS (for example) simply die on the vine.

      --
      READY.
      PRINT ""+-0
    2. Re:So who is Oracle going to buy now? by Anonymous Coward · · Score: 0

      Oh fuck every part of that. If Oracle bought RHat, RHat would die. Nobody can afford Oracle who doesn't have monopoly power.

    3. Re:So who is Oracle going to buy now? by Anonymous Coward · · Score: 0

      Going after Red Hat is a scary idea, but would seriously interfere with Microsoft's attempts to push their SQL Server product over to Linux.

      Microsoft are targeting Red Hat as their SQL Server enterprise Linux platform to compete with OracleDB. Oracle buying Red Hat would definitely upset these plans.

    4. Re: So who is Oracle going to buy now? by that+this+is+not+und · · Score: 2

      If Oracle buys RedHat so it can die, can we make sure to securely rope systemd to the body before it's sunk in the bay? Also the body of that festering millineal who champions it, of course. And Gnome3 wants to ride along.

    5. Re: So who is Oracle going to buy now? by that+this+is+not+und · · Score: 1

      Do it, Larry!

      (still bitter about the Red Hat 4.3 to 5.0 transition that motivated my move to NetBSD)

    6. Re:So who is Oracle going to buy now? by upuv · · Score: 1

      Yes it would kill RHEL. And super fast. But again Oracle would be buying the customer base. I also suspect that Oracle would only certify RHEL on certain friendly hardware platforms. AKA ones that kick back to ORACLE for said certification.

      CentOS would fork instantly and multiple other companies would try to model them selves after RedHat. Almost every RedHat project would fork as well. Git hub would go into meltdown for a few weeks I suspect.

      The Debian variant's would all of a sudden see a lot more server room time. And good old FreeBSD would see a lot more loven. Please let FreeBSD see more love. BSD is the only hope to smash Cisco's lock on switching. It would also probably drive CoreOS well and truly into the mainstream. ( As it should be. )

    7. Re:So who is Oracle going to buy now? by Anonymous Coward · · Score: 1

      If Oracle (shudder) did buy control of RedHat then as has been said, everything would be forked and a new company with mostly RedHat staff would spring up almost overnight and pick up a huge number of RedHat support customers as soon as their 'lockIn' to Oracle was over.
      That new company would soon reach the $1B in revenues while the Oracle share dwindles down to nothing. An expensive failure from Oracle? Would Larry survive such a failure?
      Interesting

    8. Re:So who is Oracle going to buy now? by that+this+is+not+und · · Score: 1

      I kind of think it would be a purification process. The kind of Red Hat people who would fit in at Oracle are the ones in charge now. Everybody beneath them would do fine at one of the forks.

      Larry would like systemd. Does he have Lennart Poettering's phone number?

    9. Re: So who is Oracle going to buy now? by pnutjam · · Score: 1

      Oracle buying Red Hat would be the best thing that ever happened to SuSE.

    10. Re:So who is Oracle going to buy now? by Anonymous Coward · · Score: 0

      Oh fuck every part of that. If Oracle bought RHat, RHat would die. Nobody can afford Oracle who doesn't have monopoly power.

      Maybe Oracle and systemd would cancel each other out?

      And what would happen when Lennart Poettering finds himself working for Larry Ellison? Would we need gravity wave detectors as the two sucking black holes of human decency merged?

    11. Re: So who is Oracle going to buy now? by Uncle+Warthog · · Score: 1

      Oracle buying Red Hat would be the best thing that ever happened to SuSE.

      Actually, they seem to insist it's SUSE now, but I'll always think of them as S.u.S.E.

    12. Re: So who is Oracle going to buy now? by Cro+Magnon · · Score: 1

      But, if you knew SuSe like I know SuSe.

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
    13. Re: So who is Oracle going to buy now? by pnutjam · · Score: 1

      I'm all openSUSE at home and used to maintain three high performance clusters with around 200 total nodes, all running SLES.
      I know and love SUSE, although it does have it's shortcomings.

    14. Re:So who is Oracle going to buy now? by goose-incarnated · · Score: 1

      Oh fuck every part of that. If Oracle bought RHat, RHat would die. Nobody can afford Oracle who doesn't have monopoly power.

      So would systemd. Without RH artificially propping it up it would have been stillborn.

      --
      I'm a minority race. Save your vitriol for white people.
  22. I started on Sun SPARC by SpaghettiPattern · · Score: 1

    I started on Sun SPARC and I'm sad to see it gone some time soon. But I'm also surprised it took that long.

    --

    I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
  23. Not "all" Solaris staff, but an awful lot of it by Anonymous Coward · · Score: 0

    In typical Oracle-style, most people, including managers losing most of their staff, were kept completely in the dark until people got calls from HR and/or severance packages via FedEx. The way that it played out was pretty bad.

    But it wasn't all Solaris staff. Who knows what things will be like for those who remain.

  24. Thank you Solaris!! by Anonymous Coward · · Score: 0

    You made me a lot of money years ago, it was a pity I blew it all on hookers and blow :)

    1. Re:Thank you Solaris!! by kevinbr · · Score: 1

      Yeah in the early 80's I made a fortune in the Middle East based on Sun, support, training and consulting. Ever since then it has been a long slow spiral down earnings wise. I guess I never got over the shift :-(

  25. OS Support? by Anonymous Coward · · Score: 0

    "Oracle has committed to support Solaris until the 2030s"

    So when the OS guy finds an interesting issue in a driver and goes to talk to the h/w guy to help sort it out.
    Oh, wait that won't work.

    Sun's run is pretty much done.

  26. The reason by Anonymous Coward · · Score: 0

    Larry Ellison wants a new boat..

     

    1. Re:The reason by that+this+is+not+und · · Score: 1

      I heard somewhere the old one lost a race recently. Is that true?

  27. RIF by Deadstick · · Score: 1

    ...is not just "Oracle-speak". Ask any civil servant.

  28. I can. Oracle is a bunch of idiots. by Anonymous Coward · · Score: 0

    ... but I can't fault him for this.

    In the olden days, highly trained smart folks could be moved to other parts of the company. Sure, there would be a few months of getting up to speed - but isn't there anyway with a new hire?
    And with moving folks you don't have the expense and bad publicity of a layoff.

    In this day and age, it's use them up and throw them out. People are a commodity - including engineers and tech people.

        So, you're a great C#,C++,SQL, GUI, whatever engineer? Too bad! Your skills do not transfer - you do not have the skills. Learn in the new position? Ah no. We need someone to hit the ground running.

    They are canning a bunch of good people just to make numbers on a balance sheet look good. And all those people hitting the job market at once? Bad news - especially for the over 40.

    "If they have the skills; they'll get a job." is a fairy tale.

    It could happen to any of us and being in management and being sent to China doesn't make one immune (I've seen entire companies get wiped out with mergers and acquisitions and the management gets laid off after they can their reports.). In tech as anywhere, the rug can be pulled out from under you at anytime and recovering is getting more and more difficult.

    1. Re:I can. Oracle is a bunch of idiots. by Anonymous Coward · · Score: 0

      GUI, whatever engineer?

      Having been forced to use a couple of Oracle applications a few years ago, I don't think Oracle had any GUI engineers so there's probably no role to transfer such people to.

  29. Payback by Anonymous Coward · · Score: 0

    Them computer weenies have cost many a honest man his job. Shove them into the shit pit I say. See how long they last, them la-di-da key pushers.

  30. System V R4 is dying by Stonent1 · · Score: 2

    They should have stuck with BSD, it's dying but less quickly. :)

  31. And the people? The REAL lesson here. by Anonymous Coward · · Score: 0

    Those folks being laid off are gonna have a real hard time. This "if they have the skills, they'll get a job." is a fairy tale. An employer will look at their skills and consider them antiquated and therefore "lack the skills".

    And the real lesson here is that people - including tech people - are a commodity to be used and disposed of at will.

    We are not indispensable can be discarded at any time.

    1. Re: And the people? The REAL lesson here. by Anonymous Coward · · Score: 0

      This is not how hiring works. Anyone who interviews regularly knows that 75% of developers can't count to 11 and the other 25% are hired.

      We're a PHP shop. We don't require PHP or any of our other tools on a resume. If you've been working in Java or C# or C++ or Ruby for years, you'll be 95% on PHP in 6 months.

  32. And why did Larry buy Sun in the first place? by whitroth · · Score: 1

    Ego?

    I knew it was bad when they bought Sun. After the first tech support disaster, and that was for a nice server, with paid NBD warranty, I started referring to dealing with them as self-abuse.

    Institutionally, I'd say they didn't know what to do with a hardware company, and weren't ready to compete with Intel chips, and probably didn't really realize the kind of financial investment that a hardware company, with their own non-Intel chipset, meant, and their ROI accountants had the vapors when they looked.

    Damn. Sic transit gloria Sol.

    1. Re:And why did Larry buy Sun in the first place? by ebvwfbw · · Score: 1

      I think it was really for Java. Made a lot of sense from his perspective actually. Run SUN for a few years and then blow it off. Exactly what I said would happen. I thought he'd keep his backup business, however. That really made sense to keep. Maybe he'll move it all over to Linux. I think we should bury SUN Solaris next to VMS and BSD. Nice little plot of land there, overlooking the river.

  33. Re: And the people? The REAL lesson here. by Uncle+Warthog · · Score: 2

    Anyone who interviews regularly knows that 75% of developers can't count to 11

    Huh? That's not hard:

      0
      1
    10
    11

  34. IBM had them long ago by Anonymous Coward · · Score: 0

    Like, back in the 90s at least. They created the first iteration of the technology in 1972, which means it's almost as old as me. That's probably why lpars were more mature. Back when I thought the NT servers/workstations that I was replacing large Novell/Win 3.1 installs with were hot shit, the mainframe guys were yawning at what I was doing and forcing me to back up ~100 servers to Adstar Distributed Storage Manager (now part of Tivoli) on a lpar. Did HSM properly in an age where Intel-based backup utilities didn't have a clue about that. This being 1995 or so.

  35. Maybe those SPARC engineers... by Anonymous Coward · · Score: 0

    Maybe those SPARC engineers could develop a new processor without any sort of AMT?

    Probably too big an effort to crowdfund.

  36. Re: And the people? The REAL lesson here. by nitehawk214 · · Score: 1

    You're hired.

    --
    I'm a good cook. I'm a fantastic eater. - Steven Brust