rang@cpsin3.cps.msu.edu (Anton Rang) (01/06/89)
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 | | +---------------------------+------------------------+----------------------+
louie@trantor.umd.edu (Louis A. Mamakos) (01/06/89)
We need source. Our computing environment is rich and varied enough that stock vendor software is often not sufficient. It is often the case that some features are missing (e.g Domain Name server support), and we need to add these features to make the systems usable in our environment. We don't expect the sources for free; we are willing to pay (a reasonable) cost for them. We don't expect the sources to everything. We can proably do without the source to NeXTStep and Display PostScript. We do, however, need the source to the Mach/UNIX kernel and the generic UNIX utilities. We don't expect NeXT to support our modified software. We do expect them to fix bugs in their stock, out of the box software. One of the factors used in choosing between multiple vendors of say, workstation systems, is the availability of source code. Our organization tends to buy DEC hardware; one reason is that source code is available in a timely fashon after a release. I have a NeXT box on my desk, and a DEC VAXStation 2000 over on the table. The NeXT box is neat, but I can't even regenerate a new kernel (even from binaries) on this machine. Why would I want to do this? Can *you* think of a way to change the timezone that the machine thinks I'm in? And that's just for starters. Never mind about adding device drivers. We don't consider a NeXT box to be in competion with Macintosh class machines; they are in competition with the DEC and SUNs of the world, and those vendors supply source. The academic market place doing research needs source code. NeXT says they are marketing to the academic.. let them back that up with some action. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
chet@pirate.CWRU.EDU (Chet Ramey) (01/06/89)
In article <1438@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: >| Anton Rang (grad student) | "VMS Forever!" | "Do worry...be SAD!" | I believe that there is more than coincidence to the placement of these two quotes :-) Chet Chet Ramey "His efforts in support of this worthy cause Network Management Group were warmly applauded by the doctors; several Case Western Reserve University nurses also gave him the clap." chet@{cwjcc,pirate}.CWRU.EDU -- "Weekend Warriors"