5 ms·

My point was that you generalised your experience with one product to all things ever produced by either company. Generalisations are usually wrong. You claim

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.

acdha 12y ago
> 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.
- binarycrusader 12y ago
  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: https://java.net/projects/ips/pages/Home https://java.net/projects/ips/pages/Home 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.

acdha 12y ago

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

binarycrusader 12y ago
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: https://java.net/projects/ips/pages/Home https://java.net/projects/ips/pages/Home 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.