This is NeXT-and-sources in view mode; [Up]
Date: Sun 22-Dec-1988 16:45:50 From: Unknown Subject: Re: NeXT and sources In article kevin@hiatus.dec.com (Kevin Baranski-Walker) writes: >> I stressed to him the importance of sources, both for system administration >> and for research ... > >Gee I got alot of work accomplished w/o MVS, RT-11, or VMS sources (pre-DEC >of course :-) There can be a lot of arguments about source/no-source. Almost all sites *think* that they do need source. Most sites have at least one hacker, and hackers by definition want source, if only to look at what other people have done. I agree that many sites don't need source, but saying that sources to the OS aren't needed is just as extreme as saying that everyone needs source. There are certain types of sites have a real need for source to the OS. Two examples if sites that don't need source: Application development. A friend of mine has a few machines (Macs currently, NeXT in the future?) and is doing some software development. He is writing a very slick tool to do dance notation. He has no need for source. Normal System Admin. Another friend is a sys-admin for a network with a few Suns. The Sun provided servers (such a YP) handle all his problems just fine. There are other sites that this just doesn't work. These sites would be characterized by one of three things: size, security concerns, or computer science research. If a site has one of these attributes it is somewhere between diffucult and impossible for them to function effectively without source. #1. Large and Complex Integration Problems There are many sites out there that have a large collection of hosts of varying types. These sites often want the systems to have access to identical services and resources. Sometimes these sites have need to drop things into the kernel. One site might have home grown tools that support distributed systems. You could say they should use the services of Mach, but they don't have Mach on most of their machines. If you can't integrate these services researchers will have trouble getting done what they want to do. Other sites might have a locally developped networking protocol, file system, etc which they need to permit integration with the rest of their machines. #2 High Security Sites. Lets face it, all software vendors are slow when it comes to distrubuting fixes. This is a fact of life right now. What happens if a major hole is found in the NeXT OS at a secure site? If they don't have source they have two choices: disconnect the machines from their network, or stop using the machines all together until the hole is fixed. Neither options is very good since it could be months until they get fixes from the vendor. #3 Research Sites I work for a computer science department. My users are researchers. One research project is investigating system preformance. Another project is looking into different ways to do distributed systems. Without sources these tasks can get very diffucult or impossible. One of the reasons that Mach has been successful (and useful) is because there was a large body of code that didn't have to be written because sources *were* available! Thinks like Mach, Project Athena, etc. can't happen without source. This is a good way to kill the future of a product. Mark A. Verber Ohio State Univ. >From: jgreely@dinosaur.cis.ohio-state.edu (J Greely)
Date: Sun 05-Jan-1989 18:25:40 From: Unknown Subject: Re: NeXT and sources (really "Do we need OS source?") In article <29954@tut.cis.ohio-state.edu>, Mark Verber (verber@cheops.cis.ohio-state.edu) writes: >In article kevin@hiatus.dec.com (Kevin Baranski-Walker) writes: >>> I stressed to him the importance of sources, both for system administration >>> and for research ... >> >>Gee I got alot of work accomplished w/o MVS, RT-11, or VMS sources (pre-DEC >>of course :-) >There can be a lot of arguments about source/no-source. Almost all >sites *think* that they do need source. I agree with this--most people think they want source for the OS. They probably don't need it, though. >I agree that many sites don't need source, >but saying that sources to the OS aren't needed is just as extreme as >saying that everyone needs source. So make the source optional (as DEC has done, I believe). That way those of us who DON'T need source don't wind up paying for it. >There are other sites that this just doesn't work. These sites would ^^^^ [not having source] >be characterized by one of three things: size, security concerns, or >computer science research. > [ ... ] >There are many sites out there that have a large collection of hosts >of varying types. These sites often want the systems to have access >to identical services and resources. Sometimes these sites have need >to drop things into the kernel. A decent OS should let you write kernel-level code *WITHOUT* needing to modify the OS itself. For instance, VMS lets you write device drivers (where I/O is involved) and user system services (for general types of things). The interfaces are documented. No source needed (though it can help by using parts as an example). Having sites modify their OS is a vendor's (support) nightmare. If a large number of changes are being made (say, implementing NFS under VMS :-) the chances that the customer will be willing to understand all of the relevant code (some 250 microfiche sheets for VMS/RMS) are pretty low. And what about upgrades? >Lets face it, all software vendors are slow when it comes to >distributing fixes. This is a fact of life right now. What happens >if a major hole is found in the NeXT OS at a secure site? This can be a problem, but having source isn't a "magic" solution. The larger, business-style vendors (DEC and IBM, say) generally are quite good about security patches (we reported one major VMS problem and got a patch tape back within a week). If we had the source, maybe we could hack around and fix the problem. Maybe we could have broken the three or four modules which depended (in non-obvious ways) on various parts of its behavior, too. >I work for a computer science department. My users are researchers. >One research project is investigating system preformance. Another >project is looking into different ways to do distributed systems. For this kind of thing, you really do generally need source. Why? Because you're writing an operating system. It's not a question of "modifying" the existing OS as much as making it do things it wasn't intended to do--adding paradigms. Of course, you then wind up with a myriad of differing versions, but that's OK for research. Just my opinions. >Mark A. Verber >Ohio State Univ. Anton +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "VMS Forever!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+ >From: gnu@hoptoad.uucp (John Gilmore)
Date: Sun 07-Jan-1989 23:16:04 From: Unknown Subject: Re: NeXT and sources (really "Do we need OS source?") I think it's great that NeXT will not provide source (except to IBM, and except for source to GNU stuff like gcc and gdb, which presumably goes to everybody). After all, I have a lot of Sun stock...
Date: Sun 28-Jan-1989 00:08:54 From: Unknown Subject: NeXT and sources Although I work at an organization which uses NeXT computers, I am speaking for myself here. I am a serious software developer. I own two DEC-20 mainframe computers (including source license). I have a NeXT at my regular job (that's what Tomobiki-Cho is), and I'm seriously considering using the NeXT as a software development platform off-work. I'm attracted to the NeXT as it has the basic functions needed, they seem to have the right ideas for software development tools, and (in spite of a personal distaste for Unix) I need a Unix platform in my environment as part of my support to my DEC-20 users (for whom continued effective communication with Unix systems is a high-priority item). I have an order form on my desk to purchase a NeXT for my personal use at home. It's filled out, and I have the funds to cover the check. There's no way in hell I'm gonna send that order in unless sources are available. Steve Jobs' arguments against distributed sources are utterly unconvincing. It seems that he has failed to learn an important lesson from the Apple experience. The Macintosh operating system is often lampooned as the "Fisher-Price operating system". It is a Mickey-Mouse OS, and the non-availability of sources guarantees it will always be a Mickey-Mouse OS. This was a strong factor which influenced me not to purchase a MacII. In my opinion, ALL sources to critical components should be available. This is not just limited to the operating system; it also includes the window system, directory browser, etc. Maybe it'd be OK if the InterfaceBuilder sources were kept secret since you could run your machine without it -- although it seems a bit silly. Source code gives the power to fix critical problems, is the ultimate documentation, and, yes, even allows customization by customers. This is not an argument to bundle sources with every NeXT. It's perfectly alright to sell sources as a separate product. Not everyone cares about sources. Not everyone will buy sources. But those who do care, care a lot. [And I have yet to hear people who don't care chorusing that "sources should not be released."] Presently, because I decline to use YP in my development environment, my NeXT is not doing host name recognition in virtually all network utilities. I am now going through the agonizing task of getting sources for individual components from the net (many of which are publicly available via FTP from Berkeley!) and rebuilding all these components to use the resolver version of gethostbyname(). It is sheer arrogance not to make sources available to customers. My reaction as a potential customer is to answer arrogance with not buying the product and not committing to the platform. Sure, I'm using a NeXT now, but a better box will come along in the future, and I'll ask my boss to take the NeXT away and give me the new box. It is not too late for NeXT to undo the damage. But every day that NeXT waffles on the issue, more damage gets done. If I didn't care, if I didn't wish NeXT success, I wouldn't be sending this message. Is NeXT listening? -- Mark -- >From: edmoy@violet.berkeley.edu
Date: Sun 31-Jan-1989 18:28:48 From: Unknown Subject: Re: NeXT and sources I just wanted to throw in my two cents worth to the outcry for source availability. Most of the folks arguing for source availability seem to be coming from a UNIX or networking standpoint. I would like to make a pitch for source availability for the AppKit. I develop applications on the Mac, using MacApp, Apple's object-oriented applications framework. It is analogous to NeXT's AppKit. Apple distributes MacApp in source-code form, and I find having the source absolutely essential to getting anything done with it. I have four points: 1. Object-oriented programming requires the programmer to have fairly precise knowledge of the protocols that have to be followed when "plugging into" an existing set of classes (i.e., the AppKit). Although _extremely good_ documentation may be able to describe the protocols sufficiently, it can never provide as precise a description as the source of what the source is expecting. 2. Software (even NeXT's!) often has bugs. When I run into a problem because some method call to an AppKit object isn't behaving as I expect, I would like to be able to find out if it's because of something I'm doing wrong, or because of a bug in the AppKit. It's much easier to determine this from the source than from documenta- tion. 3. Having the source available ought to greatly improve the quality of bug reports to NeXT. When I find a bug in MacApp, for instance, I can usually find out the exact portion of code that's in error, fix it myself, and send an _exact_ description of the bug _and_ its fix to Apple. 4. Being able to fix bugs also saves me from having to kludge around them until they're "officially" fixed. I suppose many of these points apply to having source available for all levels. I think they especially apply for object-oriented programming, considering the often complex interactions between different objects. (Smalltalk is distributed with source, isn't it?) Rick Wong Stanford University rick@jessica.stanford.edu >From: ronc@fai.UUCP (Ronald O. Christian)
Date: Sun 01-Feb-1989 22:32:27 From: Unknown Subject: Re: NeXT and sources In article <169@Portia.Stanford.EDU> rick@Jessica.stanford.edu (Rick Wong) writes: Most of the folks arguing for source availability seem to be coming from a UNIX or networking standpoint. I would like to make a pitch for source availability for the AppKit. I agree with your reasons, and will add another (which I already mentioned long ago) for distribution of user-level sources. When we get another computer on our network, I can almost always give it a set of X11 clients with very little trouble, so that the new machine can be used "seamlessly" from our Suns, HPs, RTs, etc. I can do this because I have sources to the X11 protocol and toolkit libraries as well as to the clients themselves. It becomes a (relatively) simple matter of copy-and-compile, with some occasional porting woes, to get onto a new architecture. Most NeWS clients are almost as easy, for the same reasons. The NeXT machine's only interface to the compute power other machines on the network is via a (buggy) terminal emulator running a remote login application (rlogin, telnet, etc.) It's embarassing to have such a primitive asynch-tty worldview in a window next to the spiffy applications that can run on NeXT machines. In The Old Days, we were happy to have systems connected by standards at the level of RS-232. Then if it didn't have TCP/IP it didn't come in the door. Now our users are surprised at the existence of a machine (our Encore Multimax) that still doesn't integrate into our NFS network (two years after they sold us NFS, BTW). Just as YP makes every workstation look just like another, the users simply expect remote X and NeWS clients to run on everything on our network. NeXT should distribute sources to their clients and protocol and toolkit libraries so that users can integrate the NeXT machines into their existing environments. >From: george@vax5.CIT.CORNELL.EDU
Date: Sun 03-Feb-1989 07:36:00 From: Unknown Subject: Re: NeXT and sources I think that by not distributing the sources, NeXT is making an extremely heavy commitment to fix all bugs almost immediately and generally support the software in their machines incredibly well -- much better than UNIX. Furthermore, they are promising to document their software systems superbly, a la "Inside Macintosh" plus 230 (currently published) Apple technical notes. Finally, they are taking on the burden of making their system a lot more general, so that certain users can build on existing packages, rather than having to reimplement features that have been overlooked by NeXT, Inc. NeXT does not have the resources to accomplish this. Also, the computer architecture (UNIX) is not as conducive to this type of support as the Macintosh, where anything can be patched/hacked by a knowledgeable software expert. Can anyone from NeXT respond to these issues? P.S. I can understand why the sources to Objective C, Display Postscript, and perhaps WriteNow cannot be released, since these are commercial products owned by other companies. But what about NeXT-developed sources? >From: mic@ut-emx.UUCP (Mic (... K[a-z]+) Kaczmarczik)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.