> This, however, does not mean this is the best, or > even a *good* solution. > It's terrible. For every little change it takes me > 20x the amount of time > it would if this were running on a modern system. The > mainframes draw > enough power to light up NYC. You could re-write the > whole financial > system in a more modern language (c, java, whatever) > and within a *year* > already reap the benefits in time/money. > > The state is more concerned with keeping everything > backwards compatible > and stable, to the point they don't even *attempt* to > stay somewhat > modern, at their own peril. There is a balance point, > somewhere > in-between, that has to be found. It doesn't make any > sense that we still > have a system from 1960 running the state. We still > have two digit years, > with a kludge for y2k issues. It's a mess. A new > system *could* have been > designed to replace this mess, and probably ran on a > 4u server in less > time than it takes on these monster IBM mainframes. > Not only that, but we > could get away from this terrible batch processing, > and start doing real > time work.
Your point is very well taken. I am not a proponent of stasis, however I am a strong proponent of balance when it comes to these issues; I strongly believe that *moderation* between new features and forward/backward compatibility is the optimal mix. Consider that the mind set of people who influence Linux has taught users to always be at the latest-and-greatest, because that's effectively how fixes and new functionality are delivered. The downside of that is that forward/backward compatibility is often broken out of incompetence or purposely broken in order to try and force others to accept the same point of view (Linux binary drivers, anyone?) Anyways, Astron 6.12.0 seems just fine to me; that is to say, I haven't run into any odd behaviors with it, so to insist on having the latest version 'just because' seems somehow wrong to me. For my part, I'm happy that tcsh is even included by default in Solaris, because for years that wasn't the case! Is there a concrete problem that you stumbled upon with 6.12.00 that is specifically addressed by 6.14.00? > I realize this is a gross exaggeration of the > situation in Solaris, I > don't think the version of tcsh being discussed in > Solaris is from the > 1960s. I was just using exaggeration to make a point > (clearly.) Clearly (:-) Solaris isn't anything like that at all. But many us long time users/admins of Solaris systems respect Solaris so much precisely because Sun puts so much emphasis on keeping things compatible between releases as much as possible. That is also to say, the pace of introducing new revisions of existing SW isn't as insane as in Linux, but it's kept at an acceptable pace. Where a Joe desktop User won't have a clue what all changed under the hook when s/he clicks on a few pretty icons on their single PC desktop, a sysadmin might land into big trouble if s/he is responsible for hundreds or even thousands of systems and stuff starts breaking because of the "latest-and-greatest". Which, as it turns out, wouldn't be so "great" after all. > That's the release notes for 6.14.00. I don't know if > all those "bug > fixes" have been backported to our version, but > considering the changes, > it doesn't exactly look like a "feature release" but > instead more of a > "service pack"/bugfix release. I don't think this is > a case of "latest and > greatest" -> more like latest and least buggy. That > said, I haven't looked > at the code, I don't know. Obviously you know best in > this regard. Well, looking at the bugs, except for maybe one or two in that list, all else are obscure things you normally don't run into when writing C-shell scripts (the topic of this thread). I'm sure Sun will include the new version when they're satisfied that 6.14.00 isn't breaking anything else . Meanwhile, if anyone feels that they absolutely need 6.14.00, they're certainly free to compile it and package it on their own. The inherent problem is, just because it works for me, does not automatically imply that it will work for everybody else. That's the "latest-and-greatest" problem in a nutshell. The good news is, Astron 6.14.00 compiled beautifully with Sun Studio 11 C compiler by the time I finished typing this. With -xO5 option too, which is maximum optimizations. No errors. I'll also experiment with compiling Astron 6.14.00 with Sun Studio 11's code profiling turned on, so that I might be able to optimize the binary further. A preliminary test was OK, but that's far from saying that Astron 6.14.00 works reliably on Solaris. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
