[comp.sys.next] NeXT source, how will they be used?

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