lgl@blake.acs.washington.edu (Laurence G Lundblade) (02/15/89)
It seems to me that it is important to consider how sources would be used in this university versus developer debate. Perhaps the deabte isn't so serious, for much of the use of sources at the university will be to fix security holes (especialy related to the Internet), implement local access policies to public machines, and accomodate unusual peripherals and lab equipment. I don't see how these changes will break many applications. The other use one might find at a university is good honest systems research and developement. It will be in the univsersities interest to maintain as much compatibility as possible, and those with these modified systems will take responsibility for broken applications. At the least NeXT will learn what extentions they don't want to do at a pretty low cost. Commercial system developers probably care the most about corporate and commercial clients with lots of dollars. These customers are going to want the purest, approved original system and not some university mutant. Certainly anyone hacking the system source to make their little application work should be flamed, get bad reviews in Byte and scowled at by NeXT, universitites and other comercial developers. Are there developers that would do this given the chance? That is I think source can be given to the universties with little negative effect, and some positive effect to commercial developers. I think it is poor to compare the case histories of Mac and Sun to each other for they were targeted at totaly different markets and come from very different world views. NeXT is very interesting because it is trying to be both. This is a hard place to be. (keep that asbestos on, NeXT) I think most will agree that UNIX, DEC and Mac have benefitted by having ties with universities in that the products were improved and that a generation of users and progammers grew up on these systems. Wouldn't NeXT like to maximize that benefit and give us source? Even if we don't really need it, how about just to be nice and make us feel happy? .....Laurence lgl@cac.washington.edu Networks and Distributed Computing 206-534-5617 University of washington
stevec@fornax.UUCP (Steve Cumming) (02/16/89)
I plan to buy my Very Own Computer one day soon. I want it to be fast, powerful, Unix like - as much like my working environment as possible. (networked Suns.) NeXT is a definate candidate, considered as a chunk of iron. I also have lotsa things I could do with a a 400dpi laser printer! I also want source code, for several reasons, all of which I am sure are familiar to all of us. All my own experience at work moves me to insist on source. Ever try to make a 4.3BSD vax boot from drive 3? Want your Transcript software to emit something like EPSF code so that Scribe V6+ can use it? Can't figure out why an innocent looking change in you YP databases causes password updating to silently fail? ... ad infinitum. Without source, you are out of luck. And you <don't> have to be writing bizarre device drivers or doing REAL (tm) operating systems research to find yourself up the creek. Very reasonable, ordinary every day problems can be made almost impossible without access to the code. I'll also admit a certain hacker fascination with poring over code. I find that source code can help to disambiguate overly terse manuals... :-) But this hacker root puberty stuff is secondary. I only go over source code when I <must>. Where does this leave me? I am going to wait until the FSF has a kernel working. I will then buy the highest- powered biggest-disked system that I can afford, install GNU, and do something obscene yet decorative with the distributed OS. And about two years later, if not sooner, some outfit will start selling iron that FSF kernels are specially good with. They will sell iron and peripherals only. Overheads will be low, cause they won't need mammoth, expensive systems development shops, and the whole nine yards. And a large and growing community of GNU/Mach/FSF users and experts Trailblazed together will help each other out. A fairy tale? I don't think so. When this happens, why would a University research group, or experienced users spend good money for an expensive configuration? And it may happen soon. I think that NeXT is making a big mistake. And let me add that I, too, wish them well. -- Steve Cumming stevec@lccr.cs.sfu.ca {uunet|...}!ubc-cs!fornax!stevec School of CS SFU (604) 291-4399 ... I'll be far off and gone Vancouver, CDN like summer wages.
phaedra@blake.acs.washington.edu (J. Anderson) (02/20/89)
Mr. Cumming's message sums up several reasons why I would like to see source distributed with the NeXT. I also understand (to an extent) the beliefs of the tight code people. If I were doing the source code policy at (insert your favorite hardware/software company here), I would attach with the source license a clause which states that any modifications to the kernel or utility programs on that system would silently revoke the trade name the system is running under. I.e. if I had a NeXT running the Mach kernel and decided to go and tinker with the IPC functions, no problem. At that point I am no longer running a Mach kernel. If I have a piece of software which runs on Mach and is going haywire on my system, well... I lost my right to gripe to the software vendor, to NeXT, or to anyone else when I went in to modify that kernel. Tinkers like myself (who have as a primary interest finding out what makes a certain aspect of UNIX work) have nothing to fear. Old pros who actually know what they're doing shouldn't have need to worry either. As for the people who were referred to in one of the above postings, ( Was "root puberty" the phrase I heard? ) they will be inclined to take their work a little more seriously I suppose. Credit balance: $0.02 -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. || phaedra@blake.acs.washington.edu
ronc@fai.UUCP (Ronald O. Christian) (02/22/89)
In article <882@fornax.UUCP> stevec@fornax.UUCP (Steve Cumming) writes: >Where does this leave me? I am going to wait until the >FSF has a kernel working. I will then buy the highest- >powered biggest-disked system that I can afford, install >GNU, and do something obscene yet decorative with the >distributed OS. Sadly, this will probably be a 386-based machine, not a NeXT. >And about two years later, if not sooner, some outfit will >start selling iron that FSF kernels are specially good with. >They will sell iron and peripherals only. Overheads will be >low, cause they won't need mammoth, expensive systems >development shops, and the whole nine yards. And a large >and growing community of GNU/Mach/FSF users and experts >Trailblazed together will help each other out. >A fairy tale? I don't think so. It might be a fairy tale, but to the extent it can be achieved, it's worth working for. But hell, maybe we're counting out the NeXT too quickly -- perhaps some bright CS student with MACH source and access to the cube will take the time (to the detrement of his or her social life) to port MACH to the NeXT. -- I mean a real port, one for which source code is available. Then, what next? X11, that's what. Probably necessary. There's no guarantee that a different port of MACH will be binary compatable with Next Step. Sigh. Too bad, really, I hear Next Step is a pretty good interface. Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!fai!ronc -or- ronc@fai.com
pep@notecnirp.Princeton.EDU (Pat Parseghian) (02/22/89)
Consider the irony of the situation: Where would NeXT be today without Mach? And where would Mach be today, if CMU hadn't had access to UNIX source code? NeXT may be the next computer of choice, but not the Ultimate Computer. In the post-NeXT age, will we simply toss our slick black boxes to the top of the global garbage heap? Maybe. While our behemoth VAX 11/785 across the hall endures, having crept from Ultrix to 4.3 BSD to Mach to ???. Sometimes we even let DEC boot VMS on it. There is a fragment of NeXT's market, over-represented here, that needs source code. The reasons have been stated again and again: Computer scientists need it to continue to advance the state of computing through research. Computer support people need it to make their users happy through bug finding & fixing and customization. By not providing source, NeXT cannot ensure that all NeXT boxes in the universe will appear identical to the Acme Software Systems' programmers. There will always be customers who replace standard utilities with modified versions, either written from scratch or ported under license. There will always be customers (especially at universities) who share their non-standard utilities with their colleagues. By not making source available to this minority of customers, NeXT is guaranteeing instead that this fragment of their customer base will stray farther and farther from the NeXT standard. Source should be available. Source should be accessible (i.e., reasonably priced). Source should be accurate (i.e., as current as possible). Envision a laboratory full of NeXT cubes, accessible to English and Computer Science majors alike. The latter, students in an operating systems course, have optical discs of their own - containing their first attempts at systems programming. They can boot it in the laboratory or in the dorm and inconvenience no other user when their projects inevitably crash. The English majors will never be affected. Will this vision be reality in 1989? From the support perspective, we have already wasted more time wondering "is it us?" when really "it's the software." For example, set up one client (and of course, one server). Attach the printer to the client. Now try to send a job to the printer from the server (/etc/printcap calls the printer "remote", and the client's spool directory is really on an NFS file system). SUN source differs from the Berkeley/Mach source we have; while we'll bet that this would work if the client and server were SUNs, it doesn't work if they're NeXTs. Sure, it'll be fixed in some future release, but we could have worked around it much faster (if not fixed it) if we could have seen the corresponding source. Instead of lessening the burden of the UNIX system administrator, NeXT has added to it. Pat Parseghian, Dept. of Computer Science, Princeton University, (609) 452-6261