Understandably, latest and greatest may not always be the *best* option. There is a lot to be said for stability/status quo.
However, you need to look at both ends of the spectrum. Here in the State of Hawaii, I am a data processing systems analyst in order to help fund the startup of my data center. The state has the same theory, stability/stasis mode is foremost to the bane of any modern functionality. That's why I write OS/VS COBOL and JCL on OS/360 systems. It's stable as hell, I can't recall a time where we had any failure non-hardware/power related. We run batches every night with millions of records (I specifically write/maintain the system which handle's the states finances), and we never have any issues other than the extreme processing time, huge power draw, and complete pain in the ass to maintain/modify. 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. 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.) ftp://ftp.astron.com/pub/tcsh/Announce-6.14.00 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. That being said, I'm new to Solaris. Maybe the stance is if something is buggy and put into a production release, then people might rely on those *bugs/non-intended behavior* with their programs, so you can't fix the *bugs/non-intended behavior* because it would remove backwards compatibility. I really don't know. I sure hope this isn't the case! I don't want to have to write code that relies on bugs/odd behavior simply because somebody else did 5 years ago. Cheers, David > On Tue, 11 Apr 2006, UNIX admin wrote: > >> I disagree. Having latest-and-greatest, if it comes from the Linux > camp, does not mean quality. And if the "potential user" looks mainly > > Indeed; the latest isn't necessarily the greatest. :-) > > But OTOH, there's something to be said for keeping "reasonably current". > > -- > Rich Teer, SCNA, SCSA, OpenSolaris CAB member > > President, > Rite Online Inc. > > Voice: +1 (250) 979-1638 > URL: http://www.rite-group.com/rich > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
