shwake@raysnec.UUCP (Ray Shwake) (11/23/90)
richard@pegasus.com (Richard Foulk) writes: >SCO has, so far, promised NOT to go with V.4 -- buzzing about in their own >separate reality. As I recall from an SCO presentation at our user group last December, their stated inclination is to enhance 3.2 with those components or features from V.4 most in demand. Considering the notable increase in resource requirements associated with a native V.4 environment their's is not a totally unreasonable position, though many will be uncomfortable running a "hybrid" environment. SCO can certainly speak for themselves as regards their current position. ISC, taking a different approach, reportedly will continue selling 3.2 even after 4.0 becomes available. (Is that indeed the plan?)
rcd@ico.isc.com (Dick Dunn) (11/27/90)
> >SCO has, so far, promised NOT to go with V.4 -- buzzing about in their own > >separate reality. > As I recall from an SCO presentation at our user group last December, > their stated inclination is to enhance 3.2 with those components or features > from V.4 most in demand... Interesting idea, but could someone explain how this works without giving you a result which is neither fish nor fowl? The best example I know of is long file names in a BSD-like file system; it may well be the single most- often-requested BSD feature. But if you create a modified file system with long file names, it's *going* to be incompatible, no getting around it. At that point, you're no longer a V.3.2 system, period. How do you do this? Anyone from SCO, or who's heard what SCO claims, want to explain this? [V.4's approach to the fish/fowl dilemma is to put both seafood and poultry on the menu, giving you your choice (and letting you pay for both:-) and even allowing you to have some of each.) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
vlr@litwin.com (Vic Rice) (11/28/90)
shwake@raysnec.UUCP (Ray Shwake) writes: >richard@pegasus.com (Richard Foulk) writes: >>SCO has, so far, promised NOT to go with V.4 -- buzzing about in their own >>separate reality. > As I recall from an SCO presentation at our user group last December, >their stated inclination is to enhance 3.2 with those components or features >from V.4 most in demand. Considering the notable increase in resource Wouldn't the pending release of OSF/1 have some impact on SCO's willingness to work V.4 ? -- Dr. Victor L. Rice Litwin Process Automation
rhealey@digibd.com (Rob Healey) (11/30/90)
In article <1990Nov26.194751.24747@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >> As I recall from an SCO presentation at our user group last December, >> their stated inclination is to enhance 3.2 with those components or features >> from V.4 most in demand... >Interesting idea, but could someone explain how this works without giving >you a result which is neither fish nor fowl? The best example I know of is >long file names in a BSD-like file system; it may well be the single most- >often-requested BSD feature. But if you create a modified file system with >long file names, it's *going* to be incompatible, no getting around it. At >that point, you're no longer a V.3.2 system, period. How do you do this? >Anyone from SCO, or who's heard what SCO claims, want to explain this? > Might create a BSD file system like ESIX has done. Might not be the cleanest solution but it would allow for longer file names amongs other things. This seems like a fairly obvious answer considering the FSS. Why won't this idea work? I'm sure ESIX would love to know... -Rob Speaking for self, not company.
fangchin@elaine50.stanford.edu (Chin Fang) (11/30/90)
Unfortunately, ESIX FFS is no longer a true Berkeley FFS as it was implemented by Mr. Micheal Burg a while back. Three OS programmers in ESIX development team reworked the long file name feature and made it unavailable to most users unless you like to install manually (and other than /). Please take my word, because calling ESIX regarding this is a waste of your money as I have tried. It's is not that ESIX support boys are not willing to help. It is because their current policy is that only people working on a piece of code, get to see that piece of code. I thank Mr. Micheal Burg's inside info regarding the long file name for ESIX. It is sad that is WAS a Berkeley FFS, but IS NOT now as available in rev.D. At least you won't be able to get a boot loader capable to recognize the true Berkeley FFS from ESIX, period. Chin Fang Mechanical Engineering Department Stanford University fangchin@portia.stanford.edu
shwake@raysnec.UUCP (Ray Shwake) (12/01/90)
vlr@litwin.com (Vic Rice) writes: >Wouldn't the pending release of OSF/1 have some impact on SCO's willingness >to work V.4 ? These are different issues. OSF is not based on Release 4, but rather Mach, AIX, V.2+ and other technologies.
vlr@litwin.com (Vic Rice) (12/06/90)
shwake@raysnec.UUCP (Ray Shwake) writes: >vlr@litwin.com (Vic Rice) writes: >>Wouldn't the pending release of OSF/1 have some impact on SCO's willingness >>to work V.4 ? > These are different issues. OSF is not based on Release 4, but > rather Mach, AIX, V.2+ and other technologies. Exactly !!!! Will SCO be selling any version of AT&T unix say 3 years from now. -- Dr. Victor L. Rice Litwin Process Automation