Agreed - and both Sun and Oracle have no cultural tradition of taking toolchain usability seriously. Installing updates is a complete trainwreck for almost every product they've ever released and that's one of the most basic tasks for a software vendor.
Fundamentally, I think the problem is arrogance – companies like Oracle or Sun historically assumed that their products are so important that it's someone's full-time job to deal with the rough edges, they've invested in training or reading massive doc dumps, etc. – familiar to anyone who's heard tales of mainframe operators with run books of canned solutions for each problem. Those HN commentators have the same blindspot.
In addition to usually being flat-out wrong, as the more common user is someone who just needs to do what should be a simple task which is blocking their actual real job, this ignores how profligately that mindset wastes other peoples' time and how it sets a dangerous long-term precedent where alternatives look attractive because everyone simply assumes e.g. Java, Solaris, Oracle's database etc. is hard to use and expensive.
Installing updates is a complete trainwreck for almost
every product they've ever released and that's one of the
most basic tasks for a software vendor."
Then you haven't used Solaris 11, because in general, installing updates for the OS (and Java and many other things) is as simple as: pkg update
Also, your generalisations about 'no cultural tradition of taking toolchain usability seriously' are simply not true, I can show you plenty of tools where clearly whoever was working on them did care about usability.
With that said, I'm sure you're just venting and didn't mean what you said "literally"...
We have a joke around here that if you get a job at Oracle out of college the first project they put you on is the Oracle Universal Installer. The thing has never worked. If you want to entertain yourself for a couple of weeks, try installing the latest version of the Oracle Database on the latest version of Oracle Linux. Oh, and try doing something "advanced" like using a non-default block size for the database. There is a little check box for that, but it doesn't work. You'll end up hand-editing a lot of Perl and Korn shell scripts and essentially running (and re-running) the whole install by hand. It's ridiculous. Once you get it running the software is amazing. Obviously they are capable of writing an installer. They just don't care.
You're right, I have never used Solaris 11. I stopped at Solaris 10 because the TCO was too hard to justify versus Linux – the then-new updates bricking a whole shipment of servers was the final straw for us.
I've used both Sun and Oracle products since the mid-90s. The only one which I can recall seeming to respect my time was DTrace and maybe ZFS. Oracle is by far worse (updates shipped as a flat ZIP file with text instructions where to install them?) but both really left the impression that they assumed my time was cheaper than them hiring a packaging engineer.
My point was that you generalised your experience with one product to all things ever produced by either company. Generalisations are usually wrong.
You claimed none of their products ever showed any care about usability. Yet, at last check, they all had fairly extensive documentation, accessibility work done to them, and clearly do many things that consider the user experience.
Like I said, you're clearly venting. Consider being more constructive in your comments, or at least focusing on something specific instead of just ranting.
> My point was that you generalised your experience with one product to all things ever produced by either company. Generalisations are usually wrong.
Then it's a good thing I didn't do that. I've used a number of products from both company, ranging in price from free to suites which come with 6 figure annual support contracts.
> You claimed none of their products ever showed any care about usability. Yet, at last check, they all had fairly extensive documentation, accessibility work done to them, and clearly do many things that consider the user experience.
Allow me to quote what I actually said:
> both Sun and Oracle have no cultural tradition of taking toolchain usability seriously
That's not saying that they don't do things like, say, accessibility as required to get government contracts. What I was talking about is that all of the products seemed to assume that their product was so compelling that we would be willing to invest considerable resources doing the kind of support which other vendors do as part of their job.
At multiple employers, having spent 6-8 figures on Oracle database or enterprise business applications, we used to get things like critical security updates delivered as a ZIP file with instructions for where to copy files and what permissions to set them. Sure, it's not that hard to roll a pkg, rpm, etc. but why should every customer need to do that?
One of Oracle's big enterprise apps broke when IE8 was released because the latest version still shipped a 5+ year-old JavaScript library which performed some illegal DOM operations which were now validated even in IE7 compatibility mode. When I called support, they arrogantly told me that they don't test Microsoft's software for them and would test after it was released (which was weeks in the past at this point). About a week later, a manager called me asking for a copy of the patch which I had mentioned developing so they could distribute it to other customers who had the same problem.
During the year I spent supporting that mess, our half-million-year contract didn't once get a support engineer who fixed a problem, or could even troubleshoot it without my hand-holding them through reading the error messages and eventually entering a ticket. At every point the answer was to install the latest version or reinstall what we already had, which was a long manual process with tons of hand redundant configuration in many places (many daemons on many servers). Having documentation telling you to open an XML file here and add certain blocks of text with values matching this plist over there is extensive but is not usable.
Sun wasn't as bad but they weren't well organized. Brand new V40z servers arrive with Solaris 10. The updater rendered them unbootable. Support says to try the install again, which produces the same result. Calling our sales guy says this is a known problem and they can have a systems engineer help walk us through patching a bunch of stuff by hand so the updater won't break it – great, they're supporting us but … who's paying us for the hours spent on something which would literally take 5 minutes for their QA team to reproduce? If we had thousands of them and a strong case for Solaris we might have been able to justify the time investment but it took 20 minutes to have the systems in production running Debian Linux and we spent less time on OS support over the life of hardware than trying to get a core feature to work once.
Your clarifications are helpful, but your initial post certainly didn't imply such nuance. Regardless, I appreciate you taking the time to better explain your position.
With that said, I still disagree with your conclusion that Sun and Oracle has no "cultural tradition of taking toolchain usability seriously". Again, I strongly disagree and believe that does not apply to all products or projects.
Perhaps it doesn't apply to the degree that you want, but you are claiming that it doesn't exist at all, and I can assure you that was / is not the case based on people I know that have worked on many of those projects.
At multiple employers, having spent 6-8 figures on Oracle
database or enterprise business applications, we used to
get things like critical security updates delivered as a
ZIP file with instructions for where to copy files and
what permissions to set them. Sure, it's not that hard to
roll a pkg, rpm, etc. but why should every customer need
to do that?
I completely agree that there should be a better update system; Sun was already working towards a better one which was first introduced in Solaris 11: The Image Packaging System. It was a new packaging system intended to simplify software updates for all of Sun's Solaris customers. The Glassfish team also chose to leverage for their product, distributing updates for Glassfish on Solaris, Windows, Linux and even Mac OS X via IPS.
Sun wasn't ... it took 20 minutes to have the systems in
production running Debian Linux and we spent less time on
OS support over the life of hardware than trying to get a
core feature to work once.
I sympathise, but again, this is why a completely new packaging and installation system was introduced in Solaris 11; to avoid problems like that. It helps ensure administrators have easy access to updates and always performs OS updates in a way that can be easily reverted if there's a problem.
If that's even mildly interesting to you, there's a website where both the FOSS source code for the new packaging system and the reasoning behind it is available:
The "Background Reading" section on that page has several helpful links that talk about the reasoning and philosophy behind it.
Solaris 11+ has a great update story compared to pretty much any UNIX-like system out there today. To update to the next release of the operating system, it's generally as simple as:
pkg update
Now behind that simple command lies an entire set of processes that happen each time it is executed:
1) newest "package catalog" is retrieved from the configured package repositories (local and/or remote)
2) determines which packages are installed, and what all of the newer versions of those packages are
3) parses dependencies of all packages involved to establish the transitive closure of the dependency graph
4) transforms dependencies into a set of boolean statements that can be evaluated by minisat, the boolean satisfiability solver that's used
5) takes the solution (if one is available) provided by the solver and then maps that to the equivalent set of packages
6) retrieves package manifests for all packages that will be upgraded, added, or modified
7) determines differences between installed version and target version ensuring that only files that have changed between package versions are retrieved and only files that need to be updated, installed, or removed are modified
8) organises differences based on the order they need to be executed as a single set ignoring package boundaries, performing reference counting and conflict checking
9) retrieves only the files that will be upgraded or installed as part of the operation
10) determines if the operation can be safely performed on the live system, if it cannot, it will create a snapshot of the root filesystem and clone it, otherwise, it will take a snapshot of the filesystem as a precaution before execution
11) executes planned operation, executes commands that prepare new boot environment for use, etc.
12) if operation succeeds, new boot environment (if applicable) is activated
Or put more simply, when you execute 'pkg update' on Solaris 11+, generally only a copy of the system is updated. So if the update fails, you can just pick an older boot environment from the GRUB2 menu and be right back to a working system in moments.
The other big difference from all of this, as an example, is that the package system is capable of upgrading from any older version of Solaris to any newer version of Solaris.
There are no patch readmes or zip files; administrators just update from one version to the next -- the system figures out the rest. It even knows when upgrades require a firmware update.
> Or that operating systems should be built specifically to suppport java installation?
Not even "specifically"; these updating woes rarely exist on platforms where you have a proper package manager (be it APT or YUM or Zypper or Pacman or Homebrew or whatever). Software devs shouldn't have to worry about writing updaters, since updating should be handled by the OS.
Exactly, Solaris 11 has a "proper" package manager: Network-based repositories, SAT-solver-based dependency management, signed packages, boot environments, etc.
Last time I used Solaris they didn't have proper package names. Everything was VNDRacnm where the first part was the vendor second part acronym was a minified piece of some bit of information that would have been useful if it wasn't minified.
Fundamentally, I think the problem is arrogance – companies like Oracle or Sun historically assumed that their products are so important that it's someone's full-time job to deal with the rough edges, they've invested in training or reading massive doc dumps, etc. – familiar to anyone who's heard tales of mainframe operators with run books of canned solutions for each problem. Those HN commentators have the same blindspot.
In addition to usually being flat-out wrong, as the more common user is someone who just needs to do what should be a simple task which is blocking their actual real job, this ignores how profligately that mindset wastes other peoples' time and how it sets a dangerous long-term precedent where alternatives look attractive because everyone simply assumes e.g. Java, Solaris, Oracle's database etc. is hard to use and expensive.