James Carlson wrote: > I. Szczesniak writes: > > On 5/26/09, James Carlson <James.D.Carlson at sun.com> wrote: [snip] > With either consolidation, the Perl code that's present is essentially > just what comes from the open source, as it is with _many_ projects > that happen to deliver through ON -- including, incidentally, ksh93, > where we're not doing extensive code or design reviews up to the > normal ON standards, because they'd just be infeasible. > > The big difference between the two is in makefiles: you use your own > in SFW, but you generally must use ON's in ON. That difference is why > I argued (more than once) for delivering ksh93 through SFW.
Erm... why is the ksh93-integration project dragged into this discussion and why is this particular topic dragged out of it's grave (again (anyone remeber the "Cadaver Synod" [1] ? =:-) )) ? ksh93 was _intentionally_ integrated into OS/Net because... - ... ksh88 is in OS/Net and ksh93 ws "grandfather'ed" into OS/Net as replacement for ksh88 (with the explicit comment that this is a special decision and should not be used as precendent by future projects) - ... ksh88 and ksh93 have an "intimate" relationship with libc (e.g. to implement |libc::wordexp()|) - ... it was planned to gradually "upgrade" some system commands with those in libcmd (which was implemented with ksh93-integration update1 and is now being continued with update2, update3 and update4) - ... Bourne shell is in OS/Net and IMO the "default system shell" (which is likely going to be ksh93 (see OpenSolaris/Indiana)) should be part of OS/Net and not in a different consolidation - ... we intended to use SFIO for perl (which was in OS/Net during that time) - ... we wanted libast::stdio for OS/Net applications (as consolidation-private interface) for I/O-heavy applications (since libast's stdio is significantly faster than libc's current stdio implementation (for Solaris 3.x we may get a "stdio replacement" project to replace the old stdio implementation with the libast one)) - ... we wanted to replace the existing (closed-source) pattern matching functions (e.g. |regex()|, |fnmatch()|) with the code from libast (which is opensource, faster and has very usefull extensions (which we could propose as POSIX standard if we get two implementations)) - <... AFAIK there are more reasons but I am too tired to dig them all out today (again) ...> > It'd be > simpler and lower overhead, and there's no necessary entanglement with > the rest of the core OS. I disagree that it would be "simpler and lower overhead". Yes, I know we could've "dumped" the ast-ksh package into SFWNV and build ksh93 as an monolothic all-in-one binary. However we intended to make "maximum use" of the technology provided by ksh93 and AST and therefore we decided to deliver ksh93 into OS/Net (after having three conference calls about his topic (that's why I am not happy that this decision is challanged again)), including shipping ksh93 as set of shared libraries that other applications can use it. Without doing that we would've _never_ done all the fine-tuning, testing (including integrating ksh93's own test suite into OS/Net), benchmarking, adoption for OS/Net's needs+rules (which helped us finding lots of bugs in ksh93+libast) etc. and we would've never been able to do all the work with updating the POSIX commands in OS/Net (which will now grow into it's own "POSIX commands community" (which should act as umbrella for lots of smaller projects to improve Solaris's (POSIX) command line utilities)). And "yes", it's possible to move ksh93 to SFWNV, but it would require _lots_ of work to do the move (which I do not have) and we would need lots of paperwork for interface contracts between OS/Net and SFWNV which create so much overhead that the project would quickly drown+die from that (and we could throw the idea for the POSIX commands community into the bin). Beyond that SFWNV currently has big build issues which make even a basic contribution a _PAIN_ for external people with limited resources - for example incrmental builds do not work (which means you have to clobber and rebuild everything from scratch over and over again and that just takes ~28-30h on my laptop). That's why I tried to avoid having any involvement with SFWNV unless neccesary (well, I now signed-up to do the "bash4" work to avoid that we end-up with the mess for "bash3" (which doesn't even pass it's own test suite the way it was integrated into SFWNV)) or if someone pays me for that pain. [1]=http://en.wikipedia.org/wiki/Cadaver_Synod ---- Bye, Roland P.S.: Setting Reply-To: to on-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
