On Jan 24, 2007, at 4:04 AM, James Carlson wrote: > Roy T. Fielding writes: >> I think the ARC should understand that attempting to pick >> and choose from open source alternatives while making changes to >> those products is not a feasible course of action. It is okay to do > > I think the project team should understand that ARC members not only > understand these issues, but many of them are also themselves > contributors to and maintainers of external open source software, and > have been for many years. We didn't just collectively fall off the > turnip truck. > > (In my case, yes, I've seen horrible problems on certain Linux > platforms because of the misguided ways in which the distributors > choose to hack at the PPP code. The solution to many problems is to > rip out the hacked vendor code and replace with the original > distribution. It's certainly not an unknown problem.) > > In this case, we're talking about system architecture. How that > actually gets designed, implemented, and managed is the project team's > responsibility.
I disagree. In this case (whether or not to change the coreutils to use a Solaris-specific system library), we are talking about application design regarding maintenance versus performance trade-offs. It is a decision that should be left to the original developers and it makes no economic sense to impose it on integration. > In other words, if we were to find that using the common crypto > routines was a requirement for operation on Solaris (I don't think > that's happened, but it's one of the issues being discussed), then > it's up to the project team to determine what to do about that. Yes, > forking might be a bad decision on their part. They'd likely be in > better shape overall if they can contribute the changes back to the > upstream repository. That is just imposing an internal design decision on a product because someone thinks they know better. In fact, they might know better, and it might indeed be the better choice, but it makes no difference whatsoever to the architecture of the proposal or of the system as a whole. Calling it an architecture decision is just an excuse. One-way hash algorithms are not cryptography and are not subject to the same export controls as two-way encryption. They are occasionally subject to FIPS when used within an encryption or authentication product, but that has nothing whatsoever to do with the utilities under discussion (file digesters). <http://www.gnu.org/software/coreutils/manual/html_mono/ coreutils.html#Summarizing-files> If Solaris already had utilities with the same names, interfaces, and functionality, then it would make sense to exclude the gnu ones. It would also make sense for a new project to create such tools using libmd, or to submit patches upstream to coreutils such that they would selectively make use of the operating system's supplied routines when available (assuming they don't already, which I haven't checked). What doesn't make sense is to create a barrier to entry for an *alternative* development environment based on an internal design decision over which library is used to supply an implementation. The only reason why this environment is needed is because the rest of the world did not follow the same implementation decisions as Solaris. If "do it our way" was a rational response, Solaris users wouldn't need these utilities at all. > I don't believe it's acceptable to have shackles applied to system > architecture. It's not reasonable to say that because some arbitrary > developer somewhere in the GNU universe thought that "Foo" was a good > idea, then Solaris _must_ also believe the same thing. Doing so is > abdicating our responsibility. No. The choice in that situation, were it ever to occur, is to simply not redistribute the technology. The premise here is that there exists a reason for distributing an overlay tools environment that behaves according to the GNU toolset. If doing that would violate some Solaris policy, then don't do it -- write your own tools. In this case, I don't know of any policy that applies to the constraints that have been mentioned so far. No such policy is documented on opensolaris.org. ....Roy
