matt@nanovx.UUCP (Matt Brandt) (02/11/89)
I can think of one really good reason NOT to distribute the source code that has nothing to do with NeXT being stingy. Right now, if you write a program for UNIX you have to take into account the fact that it might have berkely extensions. or sun extensions... or somebodies real time extensions. and it might run News. or it might run X11. or it might not. You can't really PLAN on anything. This makes your UNIX code about as far from portable as possible on a "portable" operating system. Maybe NeXT just wants to make sure the environment doesn't change every time you sneeze...
ram@shukra.Sun.COM (Renu Raman) (02/12/89)
In article <490@nanovx.UUCP> matt@nanovx.UUCP (Matt Brandt) writes: >I can think of one really good reason NOT to distribute the source code >that has nothing to do with NeXT being stingy. Right now, if you write a >program for UNIX you have to take into account the fact that it might have >berkely extensions. or sun extensions... or somebodies real time extensions. >and it might run News. or it might run X11. or it might not. You can't >really PLAN on anything. This makes your UNIX code about as far from >portable as possible on a "portable" operating system. > >Maybe NeXT just wants to make sure the environment doesn't change every >time you sneeze...
bet@dukeac.UUCP (Bennett Todd) (02/14/89)
>Maybe NeXT just wants to make sure the environment doesn't change every >time you sneeze... 'Twon't change at all; won't even be acquired. I spoke with a gentleman at NeXT about the source code issue; he kindly explained that the source code was being forbidden at the behest of big software houses, who want to have an absolutely stagnant unchanging target to code to. That, he claimed, is why you could buy so much user-friendly software for Macintosh and PCs and so little for Suns. I thanked him for the explanation. It makes things much clearer; I loathe Macintoshes and am not wild about PCs; NeXT is welcome to compete in that market and I don't need any, thanks. I do wish someone would compete with Sun, though; they have a monopoly, effectively, and they know it. Going the way of DEC.... -Bennett bet@orion.mc.duke.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/14/89)
In article <1234@dukeac.UUCP> bet@dukeac.UUCP (Bennett Todd) writes: >NeXT about the source code issue; he kindly explained that the source code was >being forbidden at the behest of big software houses, who want to have an >absolutely stagnant unchanging target to code to. That, he claimed, is why you >could buy so much user-friendly software for Macintosh ... Snicker. UNIX has changed a LOT less in the last five years than the macintosh operating system. Every system release breaks some developer's code. They change the ROMS. They add HFS. They add color. They add multiprocessing. All these things radically change the environment; Apple sometimes patches to work around specific applications, but eventually things have to be rewritten. The macintosh, no source included, is a developer's nightmare. The ``gentleman at NeXT'' is feeding us a lot of digested grasses, to use a polite term. -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (02/14/89)
If the ever-changing software status is the problem, why would Next not provide a test that will prove no changes in the software environment relative to the standard release? That way they'll be sure that the problem/bug is related to the genuine stuff as opposed to modified. Of course, anybody that modified the standard programs is on their own. Naturally, the fool-proof test suit may not be easy or cheep to provide, but it is really a necessity. Even AT&T had to do something (SVID, SVVS, etc.) to that effect regardless how incomplete or buggy their test suit is/was. To do otherwise would be just hiding their head in the sand. The changing nature of software will not go away, and sweeping the problem under a rug would not do anybody any good. As a matter of fact one of the secrets, in my opinion, of success of UNIX and UNIX-like systems is the ability to change with time. Please, NeXT do not kill MACH-BSD success for your own convenience! As for the living proof that software system can be successful even with constant changes just look at FSF. After all, you NeXT guys use their software as well! -- ___________________________________________________________________ Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201 UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko ARPA: zdenko@csd4.milw.wisc.edu
shane@chablis.cc.umich.edu (Shane Looker) (02/15/89)
In article <445@garcon.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>could buy so much user-friendly software for Macintosh ... > >Snicker. UNIX has changed a LOT less in the last five years than the >macintosh operating system. Every system release breaks some developer's >code. They change the ROMS. They add HFS. They add color. They add >multiprocessing. All these things radically change the environment; Apple >sometimes patches to work around specific applications, but eventually >things have to be rewritten. The macintosh, no source included, is a >developer's nightmare. > >The ``gentleman at NeXT'' is feeding us a lot of digested grasses, to >use a polite term. >Steve Dorner, U of Illinois Computing Services Office Actually, I could say the same thing about you. If you follow the rules of how to program the Macintosh, then your application is very likely to run when a new release of the system comes out. You might not understand that, comming from a Unix background, but it is what happens in the Mac world. If applications break, you can be pretty sure they were written taking shortcuts which were pointed out as not being stable in the future. (I found a demo windowing program written in 1984, which ran correctly under MultiFinder on a Mac II with color.) Shane Looker | Looker@um.cc.umich.edu | shane@chablis.cc.umich.edu
sbb@esquire.UUCP (Stephen B. Baumgarten) (02/16/89)
In article <925@mailrus.cc.umich.edu> shane@chablis.cc.umich.edu (Shane Looker) writes: >In article <445@garcon.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>>could buy so much user-friendly software for Macintosh ... >> >>Snicker. UNIX has changed a LOT less in the last five years than the >>macintosh operating system. Every system release breaks some developer's >>code. They change the ROMS. They add HFS. They add color. They add >>multiprocessing. All these things radically change the environment; Apple >>sometimes patches to work around specific applications, but eventually >>things have to be rewritten. The macintosh, no source included, is a >>developer's nightmare. >> >>The ``gentleman at NeXT'' is feeding us a lot of digested grasses, to >>use a polite term. >>Steve Dorner, U of Illinois Computing Services Office > >Actually, I could say the same thing about you. If you follow the rules of >how to program the Macintosh, then your application is very likely to run >when a new release of the system comes out. > >You might not understand that, comming from a Unix background, but it is what >happens in the Mac world. If applications break, you can be pretty sure they >were written taking shortcuts which were pointed out as not being stable in >the future. > >(I found a demo windowing program written in 1984, which ran correctly under >MultiFinder on a Mac II with color.) Yes, in general correctly written programs will work even when Apple upgrades its System software. Just because Microsoft's stuff breaks all the time is no reason to blame Apple; Inside Mac and the tech notes are quite explicit about what is and isn't approved behavior for an application. Of course, no application written in 1985 is going to be able to take advantage of 16.7 million colors on a Mac II, but if it was written correctly it should at least run under both the Finder and Multifinder, it should be able to work on any size monitor (or on multiple monitors), and it should still be able to run on any current Apple Macintosh. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
dave@onfcanim.UUCP (Dave Martindale) (02/27/89)
Maybe Next could borrow a page from aircraft licencing: Provide source code to those that need it, on the condition that any machine that is not running stock Next-supplied software have a sign saying "Experimental" on it, in a place easily visible to users. Users of Experimental machines have thus been warned that Next isn't providing support, and if something doesn't work they should call whoever is supporting that machine.
scarter@caip.rutgers.edu (Stephen M. Carter) (03/02/89)
I was once under the impression that access to source code is purely company policy. Then I started hearing that it is not so much that, but in most cases, it is with the finacial backing structure of the company. In some cases, the insurance company backing them is the one that mandates no source code. Sometimes, in special cases, a company can make a source holder a consultant (ie pay them some token amount per year) which will allow the company to give out source. By in large, a company can't do this with everybody wanting source. Any legal experts care to get into this? scarter@caip.rutgers.edu