Noticing the mailing lists, and otherwise, it seems that you want to put the sun4m support away for good (along with a similar incident done to the ZX on versions 7 & 8) and not even allow for a last supported, open "foot-in-the-door" release. Sure, used ultrasparc hardware might be cheap- but what kinds of realistic changes would have to be made if the sun4m platform was to get some sort of release that would cover as much sbus/mbus/AFX hardware as possible(to cover what was dropped in 7/8/9) for the numerous SS5/170's up to the SS/20 quad Ross 200's?
Even if the code was pulled early, there's no real reason to drop out a workable release of code(that is, something that would build cleanly for sun4m, not just raw code known not to work without unobtainable tools) for perfectly runnable machines. It'd not be much, but something based off of build 22(or whatever was the last working Solaris 10 build for sun4m) combined with proper support of sbus hardware previously dropped since Solaris 7 would be what some people are asking to have put in. Nothing purposefully crippled, nothing purposefully limited would be the intended goal of what would be wanted for the "final release" (within version 10). This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
