SunOS4.1Discussion.mail 16-Feb-90 Foote:OSBU North:Xerox Proposal for getting on 4.1Beta Date: 16-Feb-90 11:03:23 PST Subject: Proposal for getting on 4.1Beta Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "16-Feb-90 11:03:23 PST" To: Atkinson:PARC:Xerox, CHauser:PARC:Xerox, Willie-Sue:PARC:Xerox, BJackson:PARC:Xerox, Goldberg:PARC:Xerox, Pier:PARC:Xerox Cc: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox Could you take a minute to review this proposal before I send it to a wider audience? If there's something obviously broken about it I'd like to know so I don't stir up trouble. -- Jim -- 4.1Beta upgrade proposal Executive summary: I'd like to convince PFudge that it's in our best interests to migrate onto SunOS 4.1Beta. I'd like them to by into a plan to get there (I propose such a plan), then commission me to do the grunt work. Why upgrade to SunOS 4.1Beta: performance advantages bug fixes to find incompatibilities while the Beta period is open to learn how to upgrade (we'll be doing this again :-) to learn how to manage forward and backward compatibility common base with SSU (=> better testing coverage on the software exported to SSU) it looks like it's going to be awhile before we get SunOS 4.1 FCS Why not to upgrade: We may have to do it again (SunOS4.1 FCS? SunOS4.1.x?) Risk that things will break Risk that the bug fixes for 4.1Beta introduced worse bugs Potential forward compatibility issues for exported code Here are what I consider the pre-requisites to upgrading machines to 4.1Beta: 0. There ought to be consensus that about the approach before we launch into it. We can hose each other up if we do it willy-nilly. 1. The world needs to be rebuilt with the 4.1Beta tools and demonstrated to run on both 4.0.3 and 4.1Beta machines. 2. There needs to be an installation script analogous to TailorMachine.csh which will configure a freshly installed 4.1 machine to the "CSL/EDL approved" configuration, whatever that is. 3. Someone should sign up to be the upgrade co-ordinator. That person should be ready to take the heat when things go wrong (they will). Plan 1. Smodel the 4.1-built PCedarTools package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 2. Continue to build upward to RawViewersWorld and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 3. Implement and test TailorMachine4Dot1Beta.csh. 4. After sufficient grace period, smodel the 4.1 built PCedar pieces to PCedar2.0. 5. Install 4.1Beta on pool machines. More than you ever wanted to know about SunOS forward and backward compatibility: Cedar/Mesa code 4.0.3 and 4.1Beta appear to be forward and backward compatible for Cedar/Mesa code running on INSTALLED (and later) PCR's. To validate this claim I've rebuilt the PCedarTools world from CedarPreBasics up to the language tools and used these tools on 4.1 and 4.0.3 to run the language tools regression tests. I found one module that had to change to be 4.0.3/4.1 compatible (LoaderUtilsImpl.c from CedarPreBasicsExtras which had to deal with a difference in /usr/include/ctype.h). We'll continue to build upward using the 4.1 tools until we have the rest of the world built, but we currently can't see anything that looks incompatible to Cedar/Mesa code. This, of course, is largely due to the abstraction layer that PCR represents. C code C code that does not depend on Sun provided shared libraries (ie linked with the -Bstatic flag) appears to be forward and backward compatible. To validate this claim I've rebuilt the language tools drivers used by SSU to drive the Mimosa tools and they validate, forward and backward, on both 4.0.3 and 4.1. C code that depends on Sun provided shared libraries is claimed by Sun to have backward compatibility, but Sun makes no claim to support forward compatibility. This means that code compiled on 4.0.3 with shared libraries is claimed by Sun to run on 4.1 machines. But code compiled on 4.1 with shared libraries will give a load time warning when run on 4.0.3 machines. I know of know C programs that are being built or developed by CSL or EDL which would be expected to use shared libraries and to also run on pre-4.1 machines. So I don't think there is any forward or backward compatibility problems for CSL or EDL - but that doesn't mean that such problems don't exist! If anybody knows about cases like this please let me know. So my proposal is that PFudge discuss these issues, modify the plan where it needs changing, then commission me to go implement the upgrade plan. The resources I'm asking for are mainly consulting and review of this plan, but realistically PFudger's will have some disruption if we choose to upgrade. It's my hope that we can limit that disruption to the time it takes to upgrade your workstation's software, but you know how these things go. My ulterior motive: 4.1Beta includes a new assembler which includes relocation records for each procedure body. If all of PCedar were built with these tools then I could use my Bundler on PCedar code to try to improve paging behavior and improve it's performance, particularly on smaller memory machines. Obviously SSU is also very interested in tools to improve performance on smaller memory machines. 16-Feb-90 goldberg:PA:Xerox Re: Proposal for getting on 4.1Beta Date: 16-Feb-90 14:58:46 PST Subject: Re: Proposal for getting on 4.1Beta Message-ID: Originator: "goldberg%arcturia.parc.xerox:COM:Xerox", UniqueString: "16-Feb-90 14:58:46 PST" To: Foote.OSBU_North.Xerox%arisia.Xerox:COM:Xerox Cc: BJackson.parc%arisia.Xerox:COM:Xerox, CHauser.parc%arisia.Xerox:COM:Xerox, Pier.parc%arisia.Xerox:COM:Xerox, Willie-Sue.parc%arisia.Xerox:COM:Xerox, atkinson.parc%arisia.Xerox:COM:Xerox From: goldberg:PA:Xerox I've been running 4.1beta for several weeks, and it has a fairly serious problem, namely there is an nfs bug, where if you write to a filesystem mounted with 4k writes (which is what the automounter uses), the writes may be screwed up. I work around this by only compiling to my disk, rather than over nfs. We might be able to work around this by changing the automounter default to 2k or 8k. Furthermore, as Jim pointed out, ordinary c programs compiled under 4.1beta and using shared libraries will not run under 4.0.3. You get the message "ld.so: call to undefined procedure start_float from 0x4070" and they don't run. This can probably be worked around somehow. 16-Feb-90 Foote:OSBU North:Xerox Re: Proposal for getting on 4.1Beta Date: 16-Feb-90 15:46:18 PST Subject: Re: Proposal for getting on 4.1Beta In-Reply-To: Originator: "::", UniqueString: "goldberg%arcturia.parc.xerox:COM's message of 16 Feb 90 15:17:30 PST (Friday)" Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "16-Feb-90 15:46:18 PST" To: goldberg:PA:Xerox Cc: foote:OSBU North:Xerox, Atkinson:PARC:Xerox, CHauser:PARC:Xerox, Willie-Sue:PARC:Xerox, BJackson:PARC:Xerox, Pier:PARC:Xerox From: Foote:OSBU North:Xerox Ok thanks; let's add that to the list of pre-requisites: 4. A fix/workaround for the NFS bug that David Goldberg reported should be in place and tested. Details from David: > I've been running 4.1beta for several weeks, and it has a fairly > serious problem, namely there is an nfs bug, where if you write to a > filesystem mounted with 4k writes (which is what the automounter uses), > the writes may be screwed up. I work around this by only compiling to > my disk, rather than over nfs. We might be able to work around > this by changing the automounter default to 2k or 8k. The general forward compatibility problem with SunOS shared libraries isn't going to go away. At least for this update we can work around it by linking -Bstatic, but I don't know a general solution for this update or for any other. There are cases in which you can install new libraries on old kernels and make your application run - but it's problematic if the system call interface ever changes. Anybody have any ideas about how to deal with this issue? It seems too bad to be stuck on 4.0.3 forever. -- Jim 16-Feb-90 Foote:OSBU North:Xerox A Proposal for getting on 4.1Beta Date: 16-Feb-90 17:15:54 PST Subject: A Proposal for getting on 4.1Beta Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "16-Feb-90 17:15:54 PST" To: CedarPorters:PARC:Xerox Cc: Foote:OSBU North:Xerox Reply-To: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox Executive summary: I'd like to convince PFudge that it's in our best interests to migrate onto SunOS 4.1Beta. I'd like them to by into a plan to get there (I propose such a plan), then commission me to do the grunt work. Why upgrade to SunOS 4.1Beta: performance advantages bug fixes to find incompatibilities while the Beta period is open to learn how to upgrade (we'll be doing this again :-) to learn how to manage forward and backward compatibility common base with SSU (=> better testing coverage on the software exported to SSU) it looks like it's going to be awhile before we get SunOS 4.1 FCS Why not to upgrade: We may have to do it again (SunOS4.1 FCS? SunOS4.1.x?) Risk that things will break Risk that the bug fixes for 4.1Beta introduced worse bugs Potential forward compatibility issues for exported code Here are what I consider the pre-requisites to upgrading machines to 4.1Beta: 0. There ought to be consensus that about the approach before we launch into it. We can hose each other up if we do it willy-nilly. 1. The world needs to be rebuilt with the 4.1Beta tools and demonstrated to run on both 4.0.3 and 4.1Beta machines. 2. There needs to be an installation script analogous to TailorMachine.csh which will configure a freshly installed 4.1 machine to the "CSL/EDL approved" configuration, whatever that is. 3. Someone should sign up to be the upgrade co-ordinator. That person should be ready to take the heat when things go wrong (they will). 4. A fix/workaround for the NFS bug that David Goldberg reported should be in place and tested. Details from David: > I've been running 4.1beta for several weeks, and it has a fairly > serious problem, namely there is an nfs bug, where if you write to a > filesystem mounted with 4k writes (which is what the automounter uses), > the writes may be screwed up. I work around this by only compiling to > my disk, rather than over nfs. We might be able to work around > this by changing the automounter default to 2k or 8k. Plan 1. Smodel the 4.1-built PCedarTools package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 2. Continue to build upward to RawViewersWorld and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 3. Implement and test TailorMachine4Dot1Beta.csh. 4. After sufficient grace period, smodel the 4.1 built PCedar pieces to PCedar2.0. 5. Install 4.1Beta on pool machines. More than you ever wanted to know about SunOS forward and backward compatibility: Cedar/Mesa code 4.0.3 and 4.1Beta appear to be forward and backward compatible for Cedar/Mesa code running on INSTALLED (and later) PCR's. To validate this claim I've rebuilt the PCedarTools world from CedarPreBasics up to the language tools and used these tools on 4.1 and 4.0.3 to run the language tools regression tests. I found one module that had to change to be 4.0.3/4.1 compatible (LoaderUtilsImpl.c from CedarPreBasicsExtras which had to deal with a difference in /usr/include/ctype.h). We'll continue to build upward using the 4.1 tools until we have the rest of the world built, but we currently can't see anything that looks incompatible to Cedar/Mesa code. This, of course, is largely due to the abstraction layer that PCR represents. C code C code that does not depend on Sun provided shared libraries (ie linked with the -Bstatic flag) appears to be forward and backward compatible. To validate this claim I've rebuilt the language tools drivers used by SSU to drive the Mimosa tools and they validate, forward and backward, on both 4.0.3 and 4.1. C code that depends on Sun provided shared libraries is claimed by Sun to have backward compatibility, but Sun makes no claim to support forward compatibility. This means that code compiled on 4.0.3 with shared libraries is claimed by Sun to run on 4.1 machines. But code compiled on 4.1 with shared libraries will give a load time warning when run on 4.0.3 machines. The general forward compatibility problem with SunOS shared libraries isn't going to go away. At least for this update we can work around it by linking -Bstatic, but I don't know a general solution for this update or for any other. There are cases in which you can install new libraries on old kernels and make your application run - but it's problematic if the system call interface ever changes. Anybody have any ideas about how to deal with this issue? It seems too bad to be stuck on 4.0.3 forever. I know of no C programs that are being built or developed by CSL or EDL which would be expected to use shared libraries and to also run on pre-4.1 machines. So I don't think there is any forward or backward compatibility problems for CSL or EDL - but that doesn't mean that such problems don't exist! If anybody knows about cases like this please let me know. So my proposal is that PFudge discuss these issues, modify the plan where it needs changing, then commission me to go implement the upgrade plan. The resources I'm asking for are mainly consulting and review of this plan, but realistically PFudger's will have some disruption if we choose to upgrade. It's my hope that we can limit that disruption to the time it takes to upgrade your workstation's software, but you know how these things go. My ulterior motive: 4.1Beta includes a new assembler which includes relocation records for each procedure body. If all of PCedar were built with these tools then I could use my Bundler on PCedar code to try to improve paging behavior and improve it's performance, particularly on smaller memory machines. Obviously SSU is also very interested in tools to improve performance on smaller memory machines. -- Jim 19-Feb-90 mark%arisia.Xerox:COM:Xerox 4.1beta Date: 19-Feb-90 19:24:05 PST Subject: 4.1beta Message-ID: Originator: "mark%arisia.Xerox:COM:Xerox", UniqueString: "19-Feb-90 19:24:05 PST" To: cedarporters.parc%arisia.Xerox:COM:Xerox From: mark%arisia.Xerox:COM:Xerox GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Mark Weiser To: cedarporters.parc@arisia.Xerox.COM Subject: 4.1beta Return-Path: Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 19 FEB 90 19:22:36 PST Received: by arisia.Xerox.COM (5.61+/IDA-1.2.8/gandalf) id AA29622; Mon, 19 Feb 90 19:22:47 -0800 Message-Id: <9002200322.AA29622@arisia.Xerox.COM> Original-Date: Mon, 19 Feb 90 19:22:47 -0800 GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV It seems to me too early to switch to 4.1beta. There are several bad bugs reported already. Why not wait for 4.1FCS? We have enought trouble with SunOS as it is. -mark 19-Feb-90 mark%arisia.Xerox:COM:Xerox 4.1 beta performance? Date: 19-Feb-90 23:25:00 PST Subject: 4.1 beta performance? Message-ID: Originator: "mark%arisia.Xerox:COM:Xerox", UniqueString: "19-Feb-90 23:25:00 PST" To: cedarporters.parc%arisia.Xerox:COM:Xerox From: mark%arisia.Xerox:COM:Xerox GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Mark Weiser To: cedarporters.parc@arisia.Xerox.COM Subject: 4.1 beta performance? Return-Path: Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 19 FEB 90 19:26:22 PST Received: by arisia.Xerox.COM (5.61+/IDA-1.2.8/gandalf) id AA29741; Mon, 19 Feb 90 19:25:31 -0800 Message-Id: <9002200325.AA29741@arisia.Xerox.COM> Original-Date: Mon, 19 Feb 90 19:25:31 -0800 GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV BTW, a non-reason to switch seems to be performance. As far as I know, 4.1 fixes none of our performance problems. 4.1 is tuned for 8MB performance, supposedly, but the increase is supposedly modest, and supposedly zero for > 8 MB. -markm 20-Feb-90 Foote:OSBU North:Xerox Re: 4.1 beta performance? Date: 20-Feb-90 8:07:01 PST Subject: Re: 4.1 beta performance? In-Reply-To: Originator: "::", UniqueString: "mark%arisia.Xerox:COM's message of 19 Feb 90 23:25:00 PST (Monday)" Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "20-Feb-90 8:07:01 PST" To: mark%arisia.Xerox:COM:Xerox Cc: CedarPorters:PARC:Xerox Reply-To: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox > As far as I know, 4.1 fixes none of our performance problems. I was under the impression that the 4.1 kernels did not have to have the no-swap patch applied to them to get similar paging performance as 4.0.3 with the no-swap patch. In fact, I thought I'd measured this effect. Is this wrong? -- Jim 20-Feb-90 Foote:OSBU North:Xerox Re: A Proposal for getting on 4.1Beta Date: 20-Feb-90 8:43:48 PST Subject: Re: A Proposal for getting on 4.1Beta In-Reply-To: Originator: "::", UniqueString: "James K. Foote's message of 16 Feb 90 17:15:54 PST (Friday)" Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "20-Feb-90 8:43:48 PST" To: Pier:PARC:Xerox Cc: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox Would there be time to talk about this at this weeks PFudge meeting? -- Jim 22-Feb-90 Foote:OSBU North SUMMARY: "Moving to SunOS4.1" discussion Date: 22-Feb-90 14:38:07 PST Subject: SUMMARY: "Moving to SunOS4.1" discussion Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "22-Feb-90 14:38:07 PST" To: PCedarUsers:PARC:Xerox Cc: Foote:OSBU North:Xerox Reply-To: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox SUMMARY "Moving to SunOS4.1" discussion. Last week I sent a proposal to CedarPorters:PARC on how we might approach the upgrade to SunOS4.1. Here is a modified version of this proposal, followed by a summary of the discussion to date. Further discussion on this topic will be held on PCedarImplementors:PARC, I'll continue to send summaries to PCedarUsers:PARC. -- A Proposal for getting on 4.1 Pre-FCS Executive summary: I'd like to convince PFudge that it's in our best interests to migrate onto SunOS 4.1Pre-FCS. I'd like them to buy into a plan to get there (I propose such a plan), then commission me to do the grunt work. FCS means First Customer Ship. Pre-FCS is the same as FCS unless Sun finds show stopper bugs while cutting release tapes. Why upgrade to SunOS 4.1Pre-FCS: performance advantages bug fixes no-swap patch not required fix to C optimizer bugs etc. new features: modload(8) - a way to dynamically load device drivers to running systems a cleaner way for Tim to pin memory for his printer driver new assembler to enable bundling network boot server (to allow installation from a server rather than tapes) etc. to find incompatibilities while we're thinking about them to learn how to upgrade (we'll be doing this again :-) to learn how to manage forward and backward compatibility common software base with SSU (=> better testing coverage on the software exported to SSU) Why not to upgrade: we may have to do it again (SunOS4.1 FCS? SunOS4.1.x?) risk that things will break risk that the bug fixes for 4.1Pre-FCS introduced worse bugs potential forward compatibility issues for exported C code (see details below) Pre-requisites to upgrading machines to 4.1Pre-FCS: 0. There ought to be consensus that about the approach before we launch into it. We can hose each other up if we do it willy-nilly. 1. The world needs to be rebuilt with the 4.1Pre-FCS tools and demonstrated to run on both 4.0.3 and 4.1Pre-FCS machines (Done - through PCedarTools, Viewers and Tioga). 2. There needs to be an installation script analogous to TailorMachine.csh which will configure a freshly installed 4.1 machine to the "CSL/EDL approved" configuration, whatever that is. 3. Someone should sign up to be the upgrade co-ordinator. That person should be ready to take the heat when things go wrong (they will). 4. Verification that 4.1 Pre-FCS fixes the NFS bug that David Goldberg reported. Details from David: > I've been running 4.1beta for several weeks, and it has a fairly > serious problem, namely there is an nfs bug, where if you write to a > filesystem mounted with 4k writes (which is what the automounter uses), > the writes may be screwed up. I work around this by only compiling to > my disk, rather than over nfs. We might be able to work around > this by changing the automounter default to 2k or 8k. 5. PCR 2_12 is bounced to INSTALLED. 6. Server space is found for 4.1 shared files (Done). 7. Plumber is rebuilt -Bstatic (to give it forward and backward compatibility) and tested on 4.1 and 4.0.3 machines. 8. BridgeSessionD is modified for the 4.1 tty changes and is tested on 4.1 and 4.0.3 machines. Plan 1. Implement and test TailorMachine4Dot1.csh - using the new 4.1 boot server (OS installation from a file server rather than from tape). 2. Continue to build upward to RawViewersWorld and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 3. Smodel the 4.1-built PCedarTools package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 4. Smodel the 4.1-built RawViewersWorld package and get it into use on 4.1 and 4.0.3 machines to validate forward compatibility. 5. Install 4.1Pre-FCS on pioneer machines (So far Demers, Weiser, Atkinson, CHauser and Plass have voluntered). 6. After sufficient grace period make 4.1 FCS the default new machine OS (the one you install after you take your machine out of the packing crate) and install it on pool machines. 7. After sufficient grace period install 4.1Pre-FCS on non-pioneer workstations. More than you ever wanted to know about SunOS forward and backward compatibility: Cedar/Mesa code 4.0.3 and 4.1Pre-FCS appear to be forward and backward compatible for Cedar/Mesa code running on INSTALLED (and later) PCR's. To validate this claim I've rebuilt the PCedarTools world from CedarPreBasics up to the language tools and used these tools on 4.1 and 4.0.3 to run the language tools regression tests. I found one module that had to change to be 4.0.3/4.1 compatible (LoaderUtilsImpl.c from CedarPreBasicsExtras which had to deal with a difference in /usr/include/ctype.h). We'll continue to build upward using the 4.1 tools until we have the rest of the world built, but we currently can't see anything that looks incompatible to Cedar/Mesa code. This, of course, is largely due to the abstraction layer that PCR represents. C code C code that does not depend on Sun provided shared libraries (ie linked with the -Bstatic flag) appears to be forward and backward compatible. To validate this claim I've rebuilt the language tools drivers used by SSU to drive the Mimosa tools and they validate, forward and backward, on both 4.0.3 and 4.1. C code that depends on Sun provided shared libraries is claimed by Sun to have backward compatibility, but Sun makes no claim to support forward compatibility. This means that code compiled on 4.0.3 with shared libraries is claimed by Sun to run on 4.1 machines. But code compiled on 4.1 with shared libraries will give a load time warning when run on 4.0.3 machines. The general forward compatibility problem with SunOS shared libraries isn't going to go away. At least for this update we can work around it by linking -Bstatic, but I don't know a general solution for this update or for any other. There are cases in which you can install new libraries on old kernels and make your application run - but it's problematic if the system call interface ever changes. Anybody have any ideas about how to deal with this issue? It seems too bad to be stuck on 4.0.3 forever. I know of no C programs that are being built or developed by CSL or EDL which would be expected to use shared libraries and to also run on pre-4.1 machines. So I don't think there is any forward or backward compatibility problems for CSL or EDL - but that doesn't mean that such problems don't exist! If anybody knows about cases like this please let me know. So my proposal is that PFudge discuss these issues, modify the plan where it needs changing, then commission me to go implement the upgrade plan. The resources I'm asking for are mainly consulting and review of this plan, but realistically PFudger's will have some disruption if we choose to upgrade. It's my hope that we can limit that disruption to the time it takes to upgrade your workstation's software, but you know how these things go. My ulterior motive: 4.1Pre-FCS includes a new assembler which includes relocation records for each procedure body. If all of PCedar were built with these tools then I could use my Bundler on PCedar code to try to improve paging behavior and improve it's performance, particularly on smaller memory machines. Obviously SSU is also very interested in tools to improve performance on smaller memory machines. -- end of Proposal for getting on 4.1 Pre-FCS Summary of discussion to date: Alan: Nothing is obviously broken, and I think it's a fine idea. Mark: 4.1 fixes none of our (CSL/EDL) performance problems. 4.1 is tuned for 8MB performance, supposedly, but the increase is supposedly modest, and supposedly zero for > 8 MB. 4.1 Beta is also reported to have lots of bugs - let's wait for 4.1 FCS. Jim: 4.1 enables bundling which MAY have performance advantages to machines > 8MB. It was also my impression that 4.1 did not require the no-swap patch, which might indicate that they've fixed up the swapper algorithm which MAY have some performance impact. Alan: I've got a C program that uses shared libraries - I guess I'll go rebuild it -Bstatic. Jim: Can anybody think of any other prerequisites to getting the pioneers started? Jim: What about tools like "BecomeConsole" - are there others like this (C programs that we depend on that are built against SunOS shared libraries)? 23-Feb-90 Tim Diebert Moving to SunOS4.1 Date: Fri, 23 Feb 90 08:28:04 PST Sender: Tim Diebert:PARC:xerox Subject: Moving to SunOS4.1 To: Foote:OSBU North:Xerox Cc: Tim Diebert:PARC:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors^:PARC:Xerox Reply-To: Tim Diebert:PARC:xerox Jim, I think that we need to be careful with making a PCedar world that will only run on SunOS4.1. As you might know, we are involved with at least two groups at Fuji Xerox and at least one in Rank Xerox that are using PCedar. One Fuji Xerox group is considering using PCedar imaging software in a printer product. (More news on this as more details become available.) The concern that I have is related to the availablity of SunOS4.1 Export. If these folks can't get the OS, they can't run a 4.1 only PCedar. This is clearly not to say that we should support 4.0.3 forever, just until 4.1 export is available. This concern aside, let's do it! Tim 23-Feb-90 Foote:OSBU North Re: Moving to SunOS4.1 Date: 23-Feb-90 8:40:25 PST Subject: Re: Moving to SunOS4.1 In-Reply-To: Originator: "::", UniqueString: "Your message of 23 Feb 90 08:29:41 PST (Friday)" Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "23-Feb-90 8:40:25 PST" To: Tim Diebert:PARC:Xerox Cc: Foote:OSBU North:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC:Xerox Reply-To: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox > I think that we need to be careful with making a PCedar world that will only run on SunOS4.1. I wholeheartedly agree. Does anybody see anything in the proposal that would require this? -- Jim 23-Feb-90 Foote:OSBU North Re: Moving to SunOS4.1 Date: 23-Feb-90 8:48:49 PST Subject: Re: Moving to SunOS4.1 Message-ID: Originator: "James K. Foote:OSBU North:Xerox", UniqueString: "23-Feb-90 8:48:49 PST" To: Tim Diebert:PARC:Xerox Cc: Foote:OSBU North:Xerox, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC:Xerox Reply-To: Foote:OSBU North:Xerox From: Foote:OSBU North:Xerox Boy was that ever a bad sentence. Let me try again. Does anybody see anything in the proposal that would result in a PCedar that would only run on SunOS4.1? Does anyone know of a reason why PCedar's built on SunOS4.1 wouldn't run on SunOS4.0.3? -- Jim ---------------------------------------------------------------- Sender: James K. Foote:OSBU North:Xerox Date: 23 Feb 90 08:40:25 PST (Friday) Subject: Re: Moving to SunOS4.1 From: Foote To: Tim Diebert:PARC cc: Foote, Shibata:HARC:Fuji Xerox, PCedarImplementors:PARC In-Reply-to: Your message of 23 Feb 90 08:29:41 PST (Friday) Reply-to: Foote > I think that we need to be careful with making a PCedar world that will only run on SunOS4.1. I wholeheartedly agree. Does anybody see anything in the proposal that would require this? -- Jim ---------------------------------------------------------------- ��"Mail" style�J�header�AJ��(��AJ��EJ��CJ��/��.J��