"James C. McPherson" wrote: > Roland Mainz wrote: > > Do you have any idea who may be interested in implementing the proposal > > below ? > > No, I don't, unfortunately. I get the feeling though that it is an > idea whose time has come.
Well, the idea was already proposed a couple of times in the last years and noone really cared... ;-( [snip] > > - Having only one version of "make" around in Solaris/Studio products > > will likely lower the engineering costs in the long term. > > Definitely. And we as a company do not like to spend our money on > duplication of effort. And I think makeing "dmake" open source and stuffing it into ON may result in some bugfixes and/or enhanchements ... :-) > > - Sun did already lots of efforts to enhance the parallelism in > > Solaris, including the introduction of the all-new SMF startup system > > which starts services in parallel. Stuffing "dmake" at > > /usr/ccs/bin/make's place would just be the next logical step to > > explore parallelism in Solaris. > > A bit of a long bow to draw, but I get the point. We are in general > moving from serial to parallel execution of just about everything. Well, it isn't really a long bow to draw when you think what make/Makefiles can be used for. I know at least one company who just purchased Sun Workshop to have a version of "make" which can run distributed builds (or in their case: process giant amounts of input data where only a fraction changes each for each rebuild). Beyond that point there are AFAIK OS facilities which use "make" for normal work (was that YP/NIS (cannot remember anymore, we're using NIS+ :-) ) ?) and could benefit from a parallel version... > > - Sun is moving to a product line where almost every computer has > > multicore chips. Having a "make" binary which makes use of such a > > feature would be quite usefull (if anyone from Sun is looking for a > > business case... :-) ). For example the Niagara-based T1000/T2000 > > machines would get another usefull application - for "free". > > - The switch may be quite cheap to implement (looking at engineering > > time) - "dmake" already exists, is maintained and fully documented. > > Now look, you're going to have to stop stating the obvious here! I fear the answer has to be "yes" since otherwise people may not listen... ;-( And there is also the (IMO important issue) that opening "dmake" under a "free" license may help other OSes (such as "FreeBSD", "NetBSD", "DragonFly" etc.) to adopt it als default "make" version. "gmake" doesn't have many fans (and lacks "distributed" and "grid" build modes) outside Linux (at least in the *BSD variants listed above) and spreading the Workshop/Forte/Studio "dmake" may help lowering the porting efforts when porting software from those operating systems to Solaris. > JimG/Bonnie/StephenH/.... Roland is right - we should make this happen, > and sooner rather than later. I give this proposal my +1 seal of > approval. Well, I guess we need tons of +1 here from the right managers... ;-/ > > * "Contra" arguments: > > - Testing needs to be done whether dmake is 100% backwards-compatible > > to /usr/ccs/bin/make (except that there is new functionality) > > We have regression testing fiends in Ireland PerfPIT. I doubt that > this would be a real problem. Ok... [snip] > > - Sun Studio's value will decrease since another functionality gets > > integrated into the base operating system. > > One might argue that since Sun Studio has a $0 cost, that this > doesn't really matter. Well, it did matter in the past. And I guess it still has some kind of "internal" value even if the product itself is now "free" for customers (Ok Ok... this is WILD guessing... I have absolutely no clue about how to calculate the value of immaterial goods such as software... ;-/ ). Ok... what are the next steps ? Should I write an opensolaris.org project proposal ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
