cello
NETRIX Inc.
software program called 'Cello'? I tried to
ftp it from law.cornel.edu but was not
successful. It is windows based beta for use
with WWW.
Regards,
Tony
--
-----------------------------------------------
Southport Technologies Inc. Tel. 1 416 462 4606
P.O. Box 171 Fax. 1 416 512 8544
King City, Ontario L0G 1K0 BBS 1 416 512 8558
NETRIX & AST Computers Canada Online!
Internet: to...@southport.on.ca; to...@netrix.on.ca
Fidonet: 1:250/148; Cserve: 70640,3360
John Ockerbloom
>Does anyone know how I can get a copy of the
>software program called 'Cello'? I tried to
>ftp it from law.cornel.edu but was not
>successful.
Try <A HREF="ftp://fatty.law.cornell.edu/pub/LII/Cello">this link</A>.
The link given
<A HREF="http://info.cern.ch/hypertext/WWW/Windows/Status.html">at CERN</A>
has a couple of typos in it.
(I'd tell them directly, but the page in question isn't signed.)
John Ockerbloom
--
==========================================================================
ocker...@cs.cmu.edu 4209 Murray Ave., Pittsburgh PA 15217
Southport
>In <i5FRsAt...@southport.on.ca> to...@southport.on.ca (NETRIX Inc.) writes:
>>Does anyone know how I can get a copy of the
>>software program called 'Cello'? I tried to
>>ftp it from law.cornel.edu but was not
>>successful.
>Try <A HREF="ftp://fatty.law.cornell.edu/pub/LII/Cello">this link</A>.
>The link given
><A HREF="http://info.cern.ch/hypertext/WWW/Windows/Status.html">at CERN</A>
>has a couple of typos in it.
>(I'd tell them directly, but the page in question isn't signed.)
I do not have direct access to the Internet. I must go through
a UUCP connection and use the UUNET mailserver to make a ftp request.
It claims that the address fatty.law.cornel.edu does not exist.
I am not certain about the second reference you make. Is there any
way you could forward a copy of cello or point me to another site
that I can get it from?
Will Sadler
>In <CA6CFs...@cs.cmu.edu> sp...@cs.cmu.edu (John Ockerbloom) writes:
>>In <i5FRsAt...@southport.on.ca> to...@southport.on.ca (NETRIX Inc.) writes:
>>>Does anyone know how I can get a copy of the
>>>software program called 'Cello'? I tried to
>>>ftp it from law.cornel.edu but was not
>>>successful.
It is fatty.law.cornell.edu
Cornell like the school.
If you do not have direct access to the Internet you will not be able
to use Cello.
Also, the 60 day runtime version of Distinct that comes with it
is only available to US educational institutions.
There will be a winsock version out in August or September.
Will
>Regards,
>Tony
>--
>-----------------------------------------------
>Southport Technologies Inc. Tel. 1 416 462 4606
>P.O. Box 171 Fax. 1 416 512 8544
>King City, Ontario L0G 1K0 BBS 1 416 512 8558
>NETRIX & AST Computers Canada Online!
>Internet: to...@southport.on.ca; to...@netrix.on.ca
>Fidonet: 1:250/148; Cserve: 70640,3360
--
***************************************************************************
* _______________\|/_ Will Sadler wi...@cica.indiana.edu *
* Laser 44888 /|\ sad...@indiana.bitnet *
***************************************************************************
"Where's jazz going? I don't know? Maybe it's going to hell.
You can't make anything go anywhere. It just happens." Monk
Marc Andreessen
(Southport) writes:
I do not have direct access to the Internet. I must go through
a UUCP connection and use the UUNET mailserver to make a ftp request.
It claims that the address fatty.law.cornel.edu does not exist.
If you really spell Cornell with one 'l', that would explain it.
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
ma...@ncsa.uiuc.edu
Bob Peterson
|> ...
|>
|> If you do not have direct access to the Internet you will not be able
|> to use Cello.
I hope this is incorrect. We users sitting behind restrictive
firewalls can and do make use of tools such as Cello, Gopher, WWW, etc.,
to access servers running inside the company. If Cello truly will not
run without direct access to the Internet, e.g., for critical files
fetched from some support site, then the tool is seriously broken. I
suspect this is not the case.
|> ...
|> >Tony
Bob
--
Bob Peterson Work: pete...@csc.ti.com Expressway Site
Texas Instruments Home: pete...@zgnews.lonestar.org North Building
P.O. Box 655474, MS238 TIMSG: RWP Voice: +1 214 995 6080 Aisle A4
Dallas, Tx USA 75265 Fido:1:124/5148 FAX: +1 214 995 0304 2-88V97
Will Sadler
>In article <will.742755010@ogre>, wi...@ogre.cica.indiana.edu (Will Sadler) writes:
>|> ...
>|>
>|> If you do not have direct access to the Internet you will not be able
>|> to use Cello.
> I hope this is incorrect. We users sitting behind restrictive
>firewalls can and do make use of tools such as Cello, Gopher, WWW, etc.,
>to access servers running inside the company. If Cello truly will not
>run without direct access to the Internet, e.g., for critical files
>fetched from some support site, then the tool is seriously broken. I
>suspect this is not the case.
Well, by direct I mean that you can send a command like:
http://infotech.indiana.edu:80/welcome.html
And actually get the document sent to you from Indiana. If you only
have a modem and aren't running SLIP or PPP or something similar you
can't use Cello. Forgive me for the inaccurate terminology. You
wouldn't be able to guess how many people I have talked to that
want Cello but who still only have a 2400 baud dialup to Compuserv
to get their mail, and yet consider that "Internet access."
Will
Jon E. Mittelhauser
> I hope this is incorrect. We users sitting behind restrictive
>firewalls can and do make use of tools such as Cello, Gopher, WWW, etc.,
>to access servers running inside the company. If Cello truly will not
>run without direct access to the Internet, e.g., for critical files
>fetched from some support site, then the tool is seriously broken. I
>suspect this is not the case.
Well, I don't want to speak for Cello, but I believe that it is the same as
our forthcoming NCSA Mosaic for Windows. It should work fine within the
firewall as long as any URLs given are inside the firewall. It is simply a
question of what can be accessed. As long as the socket can connect to
the site in question the program should work fine.
You should be able to access any documents that are being run off an internal
server without any problems. Needless to say, documents off outside servers
are subject to the restrictions placed on you by your firewall.
To say you need direct access to the internet to "run" the program is not
accurate. To take full advantage of the program you need full access.
For that matter, it can even be run on a stand-alone system as long as
you only point to files located on the local hard disk.
-Jon
----
Jon E. Mittelhauser (jo...@ncsa.uiuc.edu)
Research Programmer, NCSA (NCSA Mosaic for MS Window, WinTelnet)
More info <a href="http://www.ncsa.uiuc.edu/SDG/People/jonm/jonm.html">here</a>
Rich Brandwein
In article <CA9F4...@csc.ti.com>, pete...@osage.csc.ti.com (Bob Peterson) writes:
|> In article <will.742755010@ogre>, wi...@ogre.cica.indiana.edu (Will Sadler) writes:
|> |> ...
|> |>
|> |> If you do not have direct access to the Internet you will not be able
|> |> to use Cello.
|>
|> I hope this is incorrect. We users sitting behind restrictive
|> firewalls can and do make use of tools such as Cello, Gopher, WWW, etc.,
|> to access servers running inside the company. If Cello truly will not
|> run without direct access to the Internet, e.g., for critical files
|> fetched from some support site, then the tool is seriously broken. I
|> suspect this is not the case.
|>
Which brings me to one of my quibbles with Cello.
We sit behind a very restrictive firewall here and have been
"proxytizing" sources to mosaic, xgopher, etc. to get it to run
to the outside world as well as in (with lots of help, when
asked, from the NCSA folks I might add). The biggest problem
I have with Cello is that it's only distributed as an executable
which means we can't proxytize it. For folks in our position, Mosaic
for windows is clearly the way to go - I assume you'll have access to the source
code.
By the way, anyone with experience/question on proxytizing let me
know. We've proxytized Mosaic/emacs/xgopher/www/lynx/tkWWW, but there's
got to be a better way to build proxy code (for instance, we
need to sit down and go back into the code each time a new version
comes out).
--
Rich Brandwein
AT&T Bell Laboratories Internet: rich.br...@att.com
Room 2G-523 Crawfords Corner Road Phone: +1(908)949-2135
Holmdel, NJ 07733-3030 Facsimile: +1(908)949-3210
Jon E. Mittelhauser
>
>Which brings me to one of my quibbles with Cello.
It is not really a Cello issue. It is more of a UNIX vs MAC/PC issue.
In the UNIX world you are forced to distribute source to allow as many
people to use it as possible. In the personal computer domain, this is
not necessary or at all common.
>
>We sit behind a very restrictive firewall here and have been
>"proxytizing" sources to mosaic, xgopher, etc. to get it to run
>to the outside world as well as in (with lots of help, when
>asked, from the NCSA folks I might add). The biggest problem
>I have with Cello is that it's only distributed as an executable
>which means we can't proxytize it. For folks in our position, Mosaic
>for windows is clearly the way to go -
>I assume you'll have access to the source code.
>
To be honest, no decision has been made regarding the windows source.
Distributing the source files is a major headache from our point of view
because it entails a large additional support requirement. There was
no choice with the X-version of Mosaic, but with the Windows and Mac
versions the executables are sufficient for the vast majority of people
who would want to run the software.
The decision will be based upon an analysis of the relative cost
and benefits of releasing the source. However, right now, I am much more
concerned with getting the source to work than if we will be releasing it
publicly or not... :^)
Even if we decide not to make the source public, I am sure that we will
attempt to work out some arrangement for those people who are stuck behind
firewalls. Needless to say, we would like as many people as possible to be
able to use our tools...
-Jon
-----
Dave Sill
>
>It is not really a Cello issue. It is more of a UNIX vs MAC/PC issue.
>In the UNIX world you are forced to distribute source to allow as many
>people to use it as possible. In the personal computer domain, this is
>not necessary or at all common.
It may not be common, but it *is* necessary if you need to ensure the code is
free of viruses and trojan horses, or need to modify the code due quirks in
the local environment, or can't rely on the distributor to provide adequate
support.
>To be honest, no decision has been made regarding the windows source.
>Distributing the source files is a major headache from our point of view
>because it entails a large additional support requirement.
What are you talking about? Incorporating fixes/enhancements submitted by
users or helping people compile the code? If the latter, can't you just
distribute the source with a disclaimer saying you won't answer questions
about build problems?
>There was
>no choice with the X-version of Mosaic, but with the Windows and Mac
>versions the executables are sufficient for the vast majority of people
>who would want to run the software.
Boo. Source code availability is a Good Thing, and I'm suprised NCSA doesn't
see that.
--
Dave Sill (d...@ornl.gov) Computers should work the way beginners
Martin Marietta Energy Systems expect them to, and one day they will.
Workstation Support -- Ted Nelson
Will Sadler
>Which brings me to one of my quibbles with Cello.
>We sit behind a very restrictive firewall here and have been
>"proxytizing" sources to mosaic, xgopher, etc. to get it to run
>to the outside world as well as in (with lots of help, when
>asked, from the NCSA folks I might add). The biggest problem
>I have with Cello is that it's only distributed as an executable
>which means we can't proxytize it. For folks in our position, Mosaic
>for windows is clearly the way to go - I assume you'll have access to the source
>code.
Rich,
I suggest that you contact Tom Bruce, the author of Cello, and ask him
about getting source code. It is still pretty messy right now, so I
know that he is hesitant about sending it out, but I imagine he will consider
it after we get out of beta.
His address is t...@begbick.law.cornell.edu
On the subject of firewalls: Do any of those suckers really work? I think
that if anyone wants to use network resources they are just going to
have to accept the fact that their hard drive may become a public resouce.
From some of the (cough cough) users I have talked to, there are very few
firewalls that are inpenetrable. Despite what the SUN reps say.
Will
Rich Brandwein
In article <1993Jul22....@ornl.gov>, d...@ORNL.GOV (Dave Sill) writes:
|> In article <CAJr1...@news.cso.uiuc.edu>, jo...@void.ncsa.uiuc.edu (Jon E. Mittelhauser) writes:
|> >
|> >It is not really a Cello issue. It is more of a UNIX vs MAC/PC issue.
|> >In the UNIX world you are forced to distribute source to allow as many
|> >people to use it as possible. In the personal computer domain, this is
|> >not necessary or at all common.
|>
|> It may not be common, but it *is* necessary if you need to ensure the code is
|> free of viruses and trojan horses, or need to modify the code due quirks in
|> the local environment, or can't rely on the distributor to provide adequate
|> support.
|>
In fact, we're not allowed by corporate policy to use binaries pulled
in from the network, here (though of course it's done all the
time...).
|> Boo. Source code availability is a Good Thing, and I'm suprised NCSA doesn't
|> see that.
|>
The funny thing about the news article is that until I got to the end
I assumed I was reading a not from the developers of Cello...
Rich Brandwein
In article <will.743353423@ogre>, wi...@ogre.cica.indiana.edu (Will Sadler) writes:
|> In <CAJ1r...@cbnewsi.cb.att.com> r...@hotsand.tbu.att.com (Rich Brandwein) writes:
|> >Which brings me to one of my quibbles with Cello.
|>
|> >We sit behind a very restrictive firewall here and have been
|> >"proxytizing" sources to mosaic, xgopher, etc. to get it to run
|> >to the outside world as well as in (with lots of help, when
|> >asked, from the NCSA folks I might add). The biggest problem
|> >I have with Cello is that it's only distributed as an executable
|> >which means we can't proxytize it. For folks in our position, Mosaic
|> >for windows is clearly the way to go - I assume you'll have access to the source
|> >code.
|> Rich,
|>
|> I suggest that you contact Tom Bruce, the author of Cello, and ask him
|> about getting source code. It is still pretty messy right now, so I
|> know that he is hesitant about sending it out, but I imagine he will consider
|> it after we get out of beta.
Thanks! I'll send him a message...
|>
|> His address is t...@begbick.law.cornell.edu
|>
|> On the subject of firewalls: Do any of those suckers really work? I think
|> that if anyone wants to use network resources they are just going to
|> have to accept the fact that their hard drive may become a public resouce.
|> From some of the (cough cough) users I have talked to, there are very few
|> firewalls that are inpenetrable. Despite what the SUN reps say.
|>
Firewalls are as good as the security consciousness of those
*inside* the company. This being the case, I'm not very impressed
with relying on them... Unfortunately, the effect of firewalls always
seems more to prevent people *inside* using stuff *outside* than
the other way around... (though this is not exactly true in reality...).
Chris Wilson
>jo...@void.ncsa.uiuc.edu (Jon E. Mittelhauser) writes:
>>It is not really a Cello issue. It is more of a UNIX vs MAC/PC issue.
>>In the UNIX world you are forced to distribute source to allow as many
>>people to use it as possible. In the personal computer domain, this is
>>not necessary or at all common.
>
>It may not be common, but it *is* necessary if you need to ensure the code is
>free of viruses and trojan horses, or need to modify the code due quirks in
>the local environment, or can't rely on the distributor to provide adequate
>support.
Well, that's basically saying you don't trust the vendor (in our case, NCSA)
to distribute a virus-free executable. If this is the case, I'm sure we
hide a few trojan horses in our code that you probably wouldn't see - have
a little faith, or don't use our software (THIS IS MY PERSONAL OPINION, NOT
NCSA POLICY.) I'll cover the second point (modifications for quirks) in a
minute- read on.
>>To be honest, no decision has been made regarding the windows source.
>>Distributing the source files is a major headache from our point of view
>>because it entails a large additional support requirement.
>
>What are you talking about? Incorporating fixes/enhancements submitted by
>users or helping people compile the code? If the latter, can't you just
>distribute the source with a disclaimer saying you won't answer questions
>about build problems?
Incorporating fixes does take time, but is generally worth it, IF the
contributors are fairly proficient.
HOWEVER, I know from experience with NCSA Telnet that disclaimers DON'T
HELP - I am still asked at least once a week for a makefile that will compile
NCSA PC Telnet with Borland C.
>>There was
>>no choice with the X-version of Mosaic, but with the Windows and Mac
>>versions the executables are sufficient for the vast majority of people
>>who would want to run the software.
>
>Boo. Source code availability is a Good Thing, and I'm suprised NCSA doesn't
>see that.
NCSA DOES see that. NCSA has also seen people take our source code and
incorporate it into (or even change it into) a commercial product, and
make lots of money off of it while NCSA itself does not. I personally
don't want to see this happen, and we haven't come up with a satisfactory
copyright notice that would prevent this, but still make it worthwhile
to distribute source.
I personally prefer distributing source code - I like to look at other
people's source instead of reinventing the wheel. HOWEVER, I also want
to reap the benefits of what I work on. That's not greed, just a sense
of fairness. I wold like to see NCSA have enough money to continue paying
me. :^|
-Chris Wilson
cwi...@ncsa.uiuc.edu
The above DOES NOT necessarily represent the opinions of my employer. It
states MY opinion, and my opinion only.
Thomas R. Bruce
r...@hotsand.tbu.att.com writes:
>The funny thing about the news article is that until I got to the end
>I assumed I was reading a not from the developers of Cello...
Well, now you can . (grin) It's developer, singular, BTW, which is why I
share some of Jon's anxiety about maintenance in the face of source-code
release.
Certainly it's necessary to fool with networking code to cope with (to my
mind) overly-restrictive environments (about which more in a minute).
I'm not sure that a general release of source code to the Net is the best
way to deal with that problem, however, particularly when the developer
is a small (meaning tiny) shop like mine. A general distribution of an
altered program to the Net -- even if the hacks in fact added
functionality -- would drown me in support mail which I would be
ill-equipped to handle. PC users by and large assume that everybody is
WordPerfect Corporation, with similar resources to bring to bear on
support problems, and with similarly monolithic control over the product.
The idea that there would be "Cello Variations" just wouldn't occur to
most of them.
Sure, when the community of users and developers overlaps considerably --
as it traditionally has with, say, Perl -- most of these kinds of
problems can be dealt with via newsgroup, or via peer pressure applied to
newcomers who don't know the ropes, or by the somewhat gentler mechanism
of an FAQ. People come to know pretty quickly who did what and who's
responsible for which. I think the PC community is too large for those
approaches to work these days -- a suspicion which is pretty quickly
confirmed by a look at comp.protocols.tcpip.ibm-pc or
comp.os.ms-windows.apps. Or comp.os.linux, for that matter, where
_everybody_ seems to be a developer. Fact is, I'm outnumbered. Severely.
As for the claim that source code is necessary to prevent viruses and
trojan horses, that's either silly or downright insulting. I don't ask
Martin Marietta to send me engineering simulations and blueprints before
I get on a plane. And I suspect that something which had been developed
in such a nefarious fashion would be caught very quickly, with fairly
nasty consequences for the fool who did it.
Provided, of course, that the code responsible for any such problem could
actually be attributed to someone -- which would most emphatically _not_
be the case if someone were to pick up source code to Cello, add some
virus code, and then repost the whole thing as an "updated" version on
ftp.cica.indiana.edu. For instance.
But this isn't really the problem here and discussing bigger issues
doesn't get Rich Brandwein very far down the road. I have exactly zero
experience with firewalls and proxytizing generally, but I'm guessing
(perhaps foolishly) that the necessary alterations would need to be made
to networking code only. If that's so (big if, slap me if I'm wrong),
would it not be an option to build a bridge module of some kind on top of
WINSOCK? Or even a proxyable WINSOCK which all could use?
Thomas R. Bruce
Thomas...@cornell.edu
Legal Information Institute
Cornell Law School
Rich Brandwein
|>
|> But this isn't really the problem here and discussing bigger issues
|> doesn't get Rich Brandwein very far down the road. I have exactly zero
|> experience with firewalls and proxytizing generally, but I'm guessing
|> (perhaps foolishly) that the necessary alterations would need to be made
|> to networking code only. If that's so (big if, slap me if I'm wrong),
|> would it not be an option to build a bridge module of some kind on top of
|> WINSOCK? Or even a proxyable WINSOCK which all could use?
|>
Sounds great if it can work! The only problem with winsock.dll is
that it varies by tcp/ip vendor, but I guess we can work around that
(i.e., I would concentrate on the PC-NFS winsock.dll to start).
Can you recommend a way to approach trying to write/alter a dll
(for the uninitiated...)? If I know where to start, I can probably
get Geoff Arnold at Sun to help figure out the missing parts, since
it's his code presumably...
Dave Sill
>
>Well, that's basically saying you don't trust the vendor (in our case, NCSA)
>to distribute a virus-free executable.
Security requires not trusting anyone that's not either accountable or proven
trustworthy. I don't think NCSA would intentionally distribute Mosaic with a
virus, and I bet they even take reasonable precautions to prevent accidental
infection, but if one can't build Mosaic from source code with their own
libraries and compilers, one can't be sure their Mosaic binary is free of
malicious code.
>If this is the case, I'm sure we
>hide a few trojan horses in our code that you probably wouldn't see -
That's about as funny as joking about having a bomb in your suitcase while
you're going through airport security.
>have
>a little faith, or don't use our software (THIS IS MY PERSONAL OPINION, NOT
>NCSA POLICY.)
Faith is not an option, I'm afraid, and if the alternative is to not use
Mosaic, then we'll have to find something else.
>HOWEVER, I know from experience with NCSA Telnet that disclaimers DON'T
>HELP - I am still asked at least once a week for a makefile that will compile
>NCSA PC Telnet with Borland C.
Yes, but with a disclaimer in place you can at least point to it when you
politely refuse to help.
>>Boo. Source code availability is a Good Thing, and I'm suprised NCSA doesn't
>>see that.
>
>NCSA DOES see that. NCSA has also seen people take our source code and
>incorporate it into (or even change it into) a commercial product, and
>make lots of money off of it while NCSA itself does not. I personally
>don't want to see this happen, and we haven't come up with a satisfactory
>copyright notice that would prevent this, but still make it worthwhile
>to distribute source.
Look at the GNU General Public License. It was designed for exactly this
purpose.
Dave Sill
>mind) overly-restrictive environments (about which more in a minute).
And, as author of the code you certainly have the option of not exerting any
extra effort to support users in "overly-restrictive environments".
>As for the claim that source code is necessary to prevent viruses and
>trojan horses, that's either silly or downright insulting.
It's not silly, and wasn't intended as an insult. We don't know you or your
development environment, and we can't (attempt to) ensure a safe computing
environment within MMES if we blindly trust every PC binary available over
the Internet.
>I don't ask Martin Marietta to send me engineering simulations and
>blueprints before I get on a plane.
That's a decision you've made voluntarily, and affects only you. If you were
buying our products for a group of people, wouldn't you feel obligated to
ensure that they were safe? How would you like it if you did ask for some
assurance that our products were safe, and we called your request "silly" or
"insulting"?
>And I suspect that something which had been developed
>in such a nefarious fashion would be caught very quickly, with fairly
>nasty consequences for the fool who did it.
What if, for whatever reasons, the author of a popular application
distributed in binary only included a time bomb in that program? Or what if
his development system becomes infected with a virus? What protection does
the user have then?
>Provided, of course, that the code responsible for any such problem could
>actually be attributed to someone -- which would most emphatically _not_
>be the case if someone were to pick up source code to Cello, add some
>virus code, and then repost the whole thing as an "updated" version on
>ftp.cica.indiana.edu. For instance.
Caveat emptor. If J. Random User installs a hacked Cello, that's his
problem. He was the one that installed the code without taking reasonable
precautions. He didn't get it from the official distribution point for
Cello and he didn't examine the code before running it to ensure that the
changes were safe.
Will Sadler
>The funny thing about the news article is that until I got to the end
>I assumed I was reading a not from the developers of Cello...
>--
I'm not sure what you mean here Rich. A small but important point:
Cello was/is written by _one_ person, who did it because he saw a need
and that was the only way to fill it.
I just want to make it clear that Cello is not the product of some megla-
media software company (insert favorite Bill Gates owned company here) with
a large team of developers and testers.
Sometimes you need to remember that when complaining about small
features.
Will
Jon E. Mittelhauser
>cwi...@void.ncsa.uiuc.edu (Chris Wilson) writes:
>>
>>Well, that's basically saying you don't trust the vendor (in our case, NCSA)
>>to distribute a virus-free executable.
>
>Security requires not trusting anyone that's not either accountable or proven
>trustworthy. I don't think NCSA would intentionally distribute Mosaic with a
>virus, and I bet they even take reasonable precautions to prevent accidental
>infection, but if one can't build Mosaic from source code with their own
>libraries and compilers, one can't be sure their Mosaic binary is free of
>malicious code.
Are you actually implying that you only put software which has source available
on your PCs? You must have pretty boring computers. I don't know of a single
commercial application which has source available.
There is a fine line between security and paranoia and parts of your post
lead me to believe that you may be on the wrong side. You are stating that
you don't trust NCSA to distribute a binary without a virus. You seem under
the (false) impression that having the source would allow you to ensure that
this wasn't the case. I don't understand this. If I wanted to put a virus
in the source, I could easily hide it in the thousands of lines of code so
that you would probably never find it. Security means only using reputable
software, scanning that software and your drive, and making backups.
The question of source with regards to firewalls is a valid one. The question
of source with regards to security is an insulting one.
>>have
>>a little faith, or don't use our software (THIS IS MY PERSONAL OPINION, NOT
>>NCSA POLICY.)
>
>Faith is not an option, I'm afraid, and if the alternative is to not use
>Mosaic, then we'll have to find something else.
The only other alternative is Cello and Tom Bruce and I have already decided
that we will follow the same policy (whatever we decide that to be).
If you want to deprive your users of a valuable tool and access to the Web
because you are afraid of viruses, it's your choice but it seems shortsighted
to me.
King_Claudius (Chris Knight)
> Well, by direct I mean that you can send a command like:
>
>http://infotech.indiana.edu:80/welcome.html
>
>And actually get the document sent to you from Indiana. If you only
>have a modem and aren't running SLIP or PPP or something similar you
>can't use Cello. Forgive me for the inaccurate terminology. You
>wouldn't be able to guess how many people I have talked to that
>want Cello but who still only have a 2400 baud dialup to Compuserv
>to get their mail, and yet consider that "Internet access."
Why couldn't someone develop a UNIX client that would basically just pass the
info on to cello and have a driver for cello to use this specialized UNIX
client? There are quite a few people who want to have graphical interfaces to
the internet resources at home but don't want to have to run SLIP to get
them...
I mean, look at how well Prodigy does...and it seems to me that cello could be
modified quickly to do similiar things. Don't close your eyes to the folks who
don't have luxuries of TCP/IP or SLIP.
--
clau...@cymbal.calpoly.edu (King_Claudius)
Dave Sill
>In article <1993Jul23.1...@ornl.gov>, d...@ORNL.GOV (Dave Sill) writes:
>> In article <CAKvp...@news.cso.uiuc.edu>, cwi...@void.ncsa.uiuc.edu (Chris Wilson) writes:
>>>incorporate it into (or even change it into) a commercial product, and
>>>make lots of money off of it while NCSA itself does not. I personally
>>>don't want to see this happen, and we haven't come up with a satisfactory
>>>copyright notice that would prevent this, but still make it worthwhile
>>>to distribute source.
>>
>> Look at the GNU General Public License. It was designed for exactly this
>> purpose.
>
No, it was designed to ensure that source code would be available for the
software.
>I certainly hope NCSA does *NOT* put NCSA Mosaic under the GNU GPL. For
>one thing, were I to wish to incorporate some of the code -- the hypertext
>widget, say -- in a commercial product, I would be perfectly happy to pay
>NCSA. If they GPL'd the code, I wouldn't be able to use it, no matter how
>much I offered. It would be demanded that I give away my effort, too.
Nonsense. You are truly ignorant in this area, sir. If Mosaic source was
under the GNU GPL, NCSA, being the copyright holder, could restribute it to
anyone else they wanted, under any terms they prefer, at any time. They could
certainly sell you the right to include parts of it in your code.
Mike Richardson
>Well, I don't want to speak for Cello, but I believe that it is the same as
>our forthcoming NCSA Mosaic for Windows. It should work fine within the
>firewall as long as any URLs given are inside the firewall. It is simply a
It would be nice if there were an option to open proxy telnet
connections for people that are behind firewalls, but who have
gateways that allow that kind of thing.
Hacking a new connect.o into the system library is easy on
a Unix box, much harder on a PC sans-source. I guess it might
be easier with a source released winsock.dll though.
Dave Sill
>
>Are you actually implying that you only put software which has source available
>on your PCs?
No, of course not. I said "Security requires not trusting anyone that's not
either accountable or proven trustworthy." Commercial vendors are accountable.
NCSA's license for Mosaic says:
UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS
SOFTWARE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT
EXPRESS OR IMPLIED WARRANTY. THE UI SHALL NOT BE LIABLE
FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE.
Which means they explicitly disclaim any accountability. That's fine with me,
as long as I can be reasonably sure (e.g., by having source code access) that
it's safe.
>There is a fine line between security and paranoia and parts of your post
>lead me to believe that you may be on the wrong side.
Security requires a certain level of paranoia. Note that I'm not a security
weenie in my job function, but I'm obligated to encourage safe computing
practices.
>You are stating that
>you don't trust NCSA to distribute a binary without a virus.
In a word, yes. I have no reason to believe a PC binary distributed by NCSA is
clean.
>You seem under
>the (false) impression that having the source would allow you to ensure that
>this wasn't the case.
It would allow me to ensure that the code was free of trojan horses and that
the compilation was performed in an environment as trustworthy as possible.
>The question of source with regards to security is an insulting one.
Don't take it personally.
>If you want to deprive your users of a valuable tool and access to the Web
>because you are afraid of viruses, it's your choice but it seems shortsighted
>to me.
You, too, would be responsible for depriving our users of the code by not
distributing the source.
Will Sadler
>Why couldn't someone develop a UNIX client that would basically just pass the
>info on to cello and have a driver for cello to use this specialized UNIX
>client? There are quite a few people who want to have graphical interfaces to
>the internet resources at home but don't want to have to run SLIP to get
>them...
Interesting idea. Since the client (Cello) would still be doing the
processing it would need to get the files. Download time at 9600
baud is still pretty slow. I'm not a programmer so I don't know.
>I mean, look at how well Prodigy does...and it seems to me that cello could be
>modified quickly to do similiar things. Don't close your eyes to the folks who
>don't have luxuries of TCP/IP or SLIP.
Believe me, we aren't. There are WWW accounts that can be logged into via
modem and will run a WWW client on a remote machine. This is a problem
that will hopefully go away once we all have Internet direct to our
houses over dial-tone. (Should I put a smiley here or not?)
Will
--
***************************************************************************
* _______________\|/_ Will Sadler wi...@cica.indiana.edu *
* Laser 44888 /|\ sad...@indiana.bitnet *
***************************************************************************
"This is a Self Preservation Society"
Marc VanHeyningen
>In <1993Jul23.1...@zeus.calpoly.edu> clau...@cymbal.calpoly.edu (King_Claudius (Chris Knight)) writes:
>
>>Why couldn't someone develop a UNIX client that would basically just pass the
>>info on to cello and have a driver for cello to use this specialized UNIX
>>client? There are quite a few people who want to have graphical interfaces to
>>the internet resources at home but don't want to have to run SLIP to get
>>them...
>
>Interesting idea. Since the client (Cello) would still be doing the
>processing it would need to get the files. Download time at 9600
>baud is still pretty slow. I'm not a programmer so I don't know.
I think the lowest common denominator is electronic mail; it gets
gatewayed and relayed and is useable for a very large number of people
who can't FTP, telnet, or HTTP directly. We won't have everyone
directly linked for quite some time. Mail is also a basic service for
people at security-concerned companies; even the most paranoid
firewall should let email through.
I know mail gateways for services like FTP exist and are somewhat
popular. Anyone from CERN who can comment on the popularity of the
mailbot there?
I'll probably implement a toy mailbot here sometime using the
message/http-{request,response} MIME types that I proposed a while
back to see if it can be done. People linked in to the net via UUCP,
Fido, or whatever should be able to look at the Web as conveniently as
their transport system allows (and getting the enticing but painfully
slow look at cool WWW stuff should encourage them to hurry up and get
on a real network. :-)
--
Marc VanHeyningen mvan...@cs.indiana.edu MIME, RIPEM & HTTP spoken here
David Neal
>wi...@ogre.cica.indiana.edu (Will Sadler) says:
>> Well, by direct I mean that you can send a command like:
>>
>>http://infotech.indiana.edu:80/welcome.html
>>
>>And actually get the document sent to you from Indiana. If you only
>>have a modem and aren't running SLIP or PPP or something similar you
>>can't use Cello. Forgive me for the inaccurate terminology. You
>>wouldn't be able to guess how many people I have talked to that
>>want Cello but who still only have a 2400 baud dialup to Compuserv
>>to get their mail, and yet consider that "Internet access."
>
>Why couldn't someone develop a UNIX client that would basically just pass the
>info on to cello and have a driver for cello to use this specialized UNIX
>client? There are quite a few people who want to have graphical interfaces to
>the internet resources at home but don't want to have to run SLIP to get
>them...
>
Were I to hackup such a thing tomorrow, you would not want to
use it. Not only would such a system defeat the idea of leaving the
resources in the hands of their developers (offline copies of
documents would probably be rarely updated), but it would
make a graphical interface frustating and slow. If you clicked
on a new resource which was not stored locally, you are talking
mail-transmission time via compuserve/prodigy for each new document.
This also completely ignores services such as wais, gopher, ftp and telnet
which would not map well or at all into an offline envrionment. They
_require_ ip connectivity for client/server interaction. Any of these
could be hooked anywhere on an http document.
Now, don't get me wrong; I'm in your shoes and want to see some
cool/cheap/easy way for people to get easy internet access at home.
But until you see ISDN at home, or someone offering super-cheap SL/IP
or PPP links it won't happen. You gotta have a car to get on the freeway,
you gotta have an IP connection to be _on_ the internet.
--
David Neal. <dn...@neosoft.com>
``But as I said, it's speculation on my part, not "the truth".''
-- David Sternlight
Ben Jackson
>>
>>Well, that's basically saying you don't trust the vendor (in our case, NCSA)
>>to distribute a virus-free executable.
>
>Security requires not trusting anyone that's not either accountable or proven
>trustworthy. I don't think NCSA would intentionally distribute Mosaic with a
>virus, and I bet they even take reasonable precautions to prevent accidental
>infection, but if one can't build Mosaic from source code with their own
>libraries and compilers, one can't be sure their Mosaic binary is free of
>malicious code.
Which is to say you read all the code you compile? I think not. Being
able to recompile might protect you from viruses, but it's certainly not
protection from "malicious code".
>>If this is the case, I'm sure we
>>hide a few trojan horses in our code that you probably wouldn't see -
>
>That's about as funny as joking about having a bomb in your suitcase while
>you're going through airport security.
I'm sure Chris will correct me if I'm wrong, but I don't think it was a
joke. The point is YOU DON'T READ THE SOURCE! You may skim a few files,
but if someone wanted to trojan you, the only protection you have is to
NOT USE THE PRODUCT.
>>have
>>a little faith, or don't use our software (THIS IS MY PERSONAL OPINION, NOT
>>NCSA POLICY.)
>
>Faith is not an option, I'm afraid, and if the alternative is to not use
>Mosaic, then we'll have to find something else.
Your loss, I'm sure.
I agree that source distribution is a Good Thing (tm), but I'm tired of
reading that, "the only way to be sure is to have the source," as if
source code couldn't contain "malicious code" as easily as the binaries.
As you've said, you have two options: use the binary or find something
else.
--
"Now it's over, I'm dead and I haven't done anything that I want, or
I'm still alive and there's nothing I want to do." -- TMBG, "Dead"
Ben Jackson, b...@ben.com, b...@cs.purdue.edu
Chris Wilson
>
>In article <22nbk2...@newsstand.cit.cornell.edu>, Thomas R. Bruce <tr...@cornell.edu> writes:
>
>|> But this isn't really the problem here and discussing bigger issues
>|> doesn't get Rich Brandwein very far down the road. I have exactly zero
>|> experience with firewalls and proxytizing generally, but I'm guessing
>|> (perhaps foolishly) that the necessary alterations would need to be made
>|> to networking code only. If that's so (big if, slap me if I'm wrong),
>|> would it not be an option to build a bridge module of some kind on top of
>|> WINSOCK? Or even a proxyable WINSOCK which all could use?
>|>
>
>Sounds great if it can work! The only problem with winsock.dll is
>that it varies by tcp/ip vendor, but I guess we can work around that
>(i.e., I would concentrate on the PC-NFS winsock.dll to start).
>Can you recommend a way to approach trying to write/alter a dll
>(for the uninitiated...)? If I know where to start, I can probably
>get Geoff Arnold at Sun to help figure out the missing parts, since
>it's his code presumably...
Having not had any experience with proxytizing myself either, I don't know
what it would require, but if it is hacing into the WINSOCK being used,
NCSA's (incomplete!) WINSOCK is on our FTP server. With source.
Our WinSock is what what used to develop Windows Mosaic, and it is what I am
currently still running. HOWEVER (disclaimer time!), it is NOT by any
means a complete WINSOCK implementation - it is missing quite a bit of
the options in the WinSock API (for example, we only do blocking sockets.)
-Chris Wilson
cwi...@ncsa.uiuc.edu
Chris Wilson
>>hide a few trojan horses in our code that you probably wouldn't see -
>
>That's about as funny as joking about having a bomb in your suitcase while
>you're going through airport security.
No, _I'm_ being realistic. You seem to think having the source code is
going to alleviate any and all concerns about Trojan Horses in a program,
and I am pointing out that that is not necessarily the case.
>>have
>>a little faith, or don't use our software (THIS IS MY PERSONAL OPINION, NOT
>>NCSA POLICY.)
>
>Faith is not an option, I'm afraid, and if the alternative is to not use
>Mosaic, then we'll have to find something else.
Or, as a third option, buy the source from us. We do sell source licenses.
Perhaps some people think this is pretty money-grubbing/mercenary of us -
well, then I say, your salary isn't on the line.
>>HOWEVER, I know from experience with NCSA Telnet that disclaimers DON'T
>>HELP - I am still asked at least once a week for a makefile that will compile
>>NCSA PC Telnet with Borland C.
>
>Yes, but with a disclaimer in place you can at least point to it when you
>politely refuse to help.
But it is still a waste of my time to answer these requests. Even if I know
the answers to all inquiries about the source code of Telnet, it still takes
my time to answer them.
>>>Boo. Source code availability is a Good Thing, and I'm suprised NCSA doesn't
>>>see that.
>>
>>NCSA DOES see that. NCSA has also seen people take our source code and
>>incorporate it into (or even change it into) a commercial product, and
>>make lots of money off of it while NCSA itself does not. I personally
>>don't want to see this happen, and we haven't come up with a satisfactory
>>copyright notice that would prevent this, but still make it worthwhile
>>to distribute source.
>
>Look at the GNU General Public License. It was designed for exactly this
>purpose.
No, it wasn't, really. The GNU GPL was designed to make source free. We
are not trying to do this. NCSA would like to make enough money off this
to stick around for a while, but still make our software as free as possible
for as many people as possible.
-Chris Wilson
cwi...@ncsa.uiuc.edu
Once again, this is my opinion, not NCSA's. I am not a spokesperson for
NCSA, and I shouldn't be considered as one.
Chris Wilson
> Thomas R. Bruce <tr...@cornell.edu> writes:
>>I don't ask Martin Marietta to send me engineering simulations and
>>blueprints before I get on a plane.
>
>That's a decision you've made voluntarily, and affects only you. If you were
>buying our products for a group of people, wouldn't you feel obligated to
>ensure that they were safe? How would you like it if you did ask for some
>assurance that our products were safe, and we called your request "silly" or
>"insulting"?
So, would you? Or would you publish (i.e., make FREELY AVAILABLE) _ALL_
engineering information having to do with your latest innovation? (that is,
really, what you are asking us to do.) It would become kind of difficult
to compete with other companies in your field, I would think.
>>Provided, of course, that the code responsible for any such problem could
>>actually be attributed to someone -- which would most emphatically _not_
>>be the case if someone were to pick up source code to Cello, add some
>>virus code, and then repost the whole thing as an "updated" version on
>>ftp.cica.indiana.edu. For instance.
>
>Caveat emptor. If J. Random User installs a hacked Cello, that's his
>problem. He was the one that installed the code without taking reasonable
>precautions. He didn't get it from the official distribution point for
>Cello and he didn't examine the code before running it to ensure that the
>changes were safe.
Joe User might not necessarily KNOW that his was a hacked Cello. He might
not have any idea what the official distribution point for Cello is.
If you would respond that it is his fault for not being more conscientous (sp?)
about the software he puts on his machine, then think about this -
we (meaning NCSA and Tom Bruce, with our respective current policies) are
providing a greater measure of protection for Joe Average User. Users with
special security needs, such as MM, are left in the lurch by this... but,
as I mentioned before, at least in the case of Mosaic, you CAN purchase the
source code. Or, alternatively, take this up with someone higher up in NCSA,
like Joseph Hardin - perhaps an arrangement could be reached. Once again,
I am but a cog in the NCSA machine.
-Chris Wilson
cwi...@ncsa.uiuc.edu
My opinion. You know the routine.
Chris Wilson
NCSA Mosaic for Windows was originally developed using our own WinSock
library (which is NOT a complete implementation of the Microsoft WINSOCK API).
The source code for this IS available from our FTP server (ftp.ncsa.uiuc.edu,
141.142.20.50). I'm still using this library for development.
-Chris Wilson
cwi...@ncsa.uiuc.edu
Sean Fuller
one of the later versions of socks it will be difficult to do what you
are asking. I think the way to handle this is to write a program
that automagically filters through the code and changes connects,
accepts, listens and such over to Rconnects, Rlistens, etc. I am planning
on doing this for our proxy software, because I am now supporting
Xgopher, sgopher, ftp, Xmosaic, etc. and it is getting to be a pain
modifying the software. Because it is such a simple an straight forward
conversion process for our proxy libs it will also allow us to easily
convert new software we get to work inside the firewall. Our proxy
libs cannot be made available to the public, but if you have any questions
about how to write one I will gladly answer them.
Rich Brandwein
In article <CAs94...@news.cso.uiuc.edu>, cwi...@void.ncsa.uiuc.edu (Chris Wilson) writes:
|>
|> NCSA Mosaic for Windows was originally developed using our own WinSock
|> library (which is NOT a complete implementation of the Microsoft WINSOCK API).
|> The source code for this IS available from our FTP server (ftp.ncsa.uiuc.edu,
|> 141.142.20.50). I'm still using this library for development.
|>
One question - all the TCP/IP vendors seem to provide their own
winsock.dll implementations. This gave me the impression that
winsock.dll was tied to the users TCP/IP implementation somehow.
Am I way off base? If they're not tied to the stack implementations
I would be ecstatic - one proxytized winsock.dll would fit all...
Russell McOrmond
: In article <CAJ1r...@cbnewsi.cb.att.com> rich.br...@att.com writes:
: >
: >Which brings me to one of my quibbles with Cello.
:
: It is not really a Cello issue. It is more of a UNIX vs MAC/PC issue.
If you are correct, it's also a good reason to stay away from Mac's and
PC's. One cannot support something that they have no way of fixing, and I've
yet to use a binary for any computer that did exactly what I needed it to
do - Most often a small source change is required.
: In the UNIX world you are forced to distribute source to allow as many
: people to use it as possible. In the personal computer domain, this is
: not necessary or at all common.
While I agree that it is not 'common', it is just as necessary - I myself
have been trying to get up a series of utilities for use at the local
University - A group Gopher/POP/NMPP/SecureNNTP clients. At this point
it looks like it will be easieer for me to try to port some Unix
utility to DOS than to try to get the tools in 'binary-only' form and
try to beat them into submission.
(P.S. If anyone does have any utilities for DOS that do any of the above
and come with sources I would be VERY interested in hearing
about it!)
: Distributing the source files is a major headache from our point of view
: because it entails a large additional support requirement. There was
Then stick a disclaimer in the archive and tell anyone asking questions
to 'shove off' - "We are willing to support this binary, but we will not
in any way support the sources or any derivatives of this product - We
will also not apply diffs or accept the donated work of the many people
out on the networks that would be willing to add features to our products
for free" <half grin>.
: Jon E. Mittelhauser (jo...@ncsa.uiuc.edu)
: Research Programmer, NCSA (NCSA Mosaic for MS Window, WinTelnet)
: More info <a href="http://www.ncsa.uiuc.edu/SDG/People/jonm/jonm.html">here</a>
---
Russell McOrmond, Ottawa Ontario, Canada | Opinions expressed
Freenet: aa...@freenet.carleton.ca (Faster) | in this message are
Home: r...@Atronx.OCUnix.On.Ca | my own and I
FidoNet 1:163/109 Current WPL | represent nobody
WPL Help 1:1/139 keeper of sources. | else.
Dave Sill
The background here is that NCSA distributes the source code for the
X-based version of Mosaic, their WWW interface, but doesn't intend to
distribute the source for the PC version. Their argument (correct me if
I'm wrong) is that they had to distribute the source for the X version
because there are too many platforms for them to distribute executables.
I'm arguing that there are several advantages to at least
additionally distributing source code, one of which is security,
specifically prevention of virus and trojan horse distribution.
In article <CArB8...@mentor.cc.purdue.edu>, bjac...@mentor.cc.purdue.edu (Ben Jackson) writes:
>In article <1993Jul23.1...@ornl.gov> d...@ORNL.GOV (Dave Sill) writes:
>>
>>Security requires not trusting anyone that's not either accountable or proven
>>trustworthy. I don't think NCSA would intentionally distribute Mosaic with a
>>virus, and I bet they even take reasonable precautions to prevent accidental
>>infection, but if one can't build Mosaic from source code with their own
>>libraries and compilers, one can't be sure their Mosaic binary is free of
>>malicious code.
>
>Which is to say you read all the code you compile? I think not.
Whether I do or not is irrelevant. Our company's security policy wisely
prohibits installation of precompiled binaries for free software. I say
"wisely" for reasons I've already explained.
>Being able to recompile might protect you from viruses, but it's
>certainly not protection from "malicious code".
It's not sufficient to protect against malicious code, but it's
necessary.
>>>If this is the case, I'm sure we
>>>hide a few trojan horses in our code that you probably wouldn't see -
>
>>>That's about as funny as joking about having a bomb in your suitcase while
>>you're going through airport security.
>
>I'm sure Chris will correct me if I'm wrong, but I don't think it was a
>joke.
You're asserting that NCSA hides trojan horses in their code?
>The point is YOU DON'T READ THE SOURCE! You may skim a few files,
>but if someone wanted to trojan you, the only protection you have is to
>NOT USE THE PRODUCT.
No, the point is IF YOU CAN'T GUARANTEE YOUR PROGRAM IS SAFE, AND YOU
WON'T LET ME CHECK IT, I CAN'T RUN IT!
>>Faith is not an option, I'm afraid, and if the alternative is to not use
>>Mosaic, then we'll have to find something else.
>
>Your loss, I'm sure.
The developer loses, too, when people can't run his application.
Ben Jackson
>[Cross-posted to comp.security.]
>
>I'm arguing that there are several advantages to at least
>additionally distributing source code, one of which is security,
>specifically prevention of virus and trojan horse distribution.
And as you admit later, source distribution prevents neither, although
it conceivably could IF you scrutinized the source before compiling and
installing it. Even if you took that step, someone who wanted to include
a trojan horse in their code would probably be able to hide it.
>In article <CArB8...@mentor.cc.purdue.edu>, I (Ben Jackson) wrote:
>>Which is to say you read all the code you compile? I think not.
>
>Whether I do or not is irrelevant. Our company's security policy wisely
>prohibits installation of precompiled binaries for free software. I say
>"wisely" for reasons I've already explained.
It is NOT irrelevant. Claiming that what I say is irrelevant, with no
support for that argument, is just a cheezy tactic to avoid the issue.
How does having the source protect you if you don't read it? As far as
I can tell, it simply takes up disk space.
I think that this so-called "wisdom" needs more support. How, and I would
like specifics, please, does having the source code protect you from
viruses and trojan horses?
The fourth level of > is Chris Wilson:
>>>>If this is the case, I'm sure we
>>>>hide a few trojan horses in our code that you probably wouldn't see -
>>
>>>>That's about as funny as joking about having a bomb in your suitcase while
>>>you're going through airport security.
>>
>>I'm sure Chris will correct me if I'm wrong, but I don't think it was a
>>joke.
>
>You're asserting that NCSA hides trojan horses in their code?
Well, as Chris DID state in another article, he is not kidding. I'll ignore
your petty attack, but in case you really don't understand, the point is
IT'S POSSIBLE to hide trojan horses in the source code. No, that doesn't
imply that I do it. No, that doesn't imply that NCSA does it. What it
means is someone COULD do it, and having the source gives you ZERO
protection against that method of attack.
>>The point is YOU DON'T READ THE SOURCE! You may skim a few files,
>>but if someone wanted to trojan you, the only protection you have is to
>>NOT USE THE PRODUCT.
>
>No, the point is IF YOU CAN'T GUARANTEE YOUR PROGRAM IS SAFE, AND YOU
>WON'T LET ME CHECK IT, I CAN'T RUN IT!
Which brings us back to my point, which is that YOU DON'T CHECK IT! If
you did, then I could understand your request. However, if the Cello
developers were to distribute the source, you would ftp it and compile
it, but you would NOT take the time to check the code for trojan horses
(and as we've pointed out before, any skilled programmer could hide them
from you easily).
Once again, I want to say that I am in favor of source code distribution.
There are plenty of good reasons to distribute source, but yours is not
one of them. If the developers of Cello don't want to distribute source,
that is their choice. I think you have made it clear that by denying
source access, they are losing a potential segment of their market, and
they have acknowledged that. You are still faced with the same decision:
use the binary or find another application.
Bennet Yee
bjac...@mentor.cc.purdue.edu (Ben Jackson) questions how having
source to a program that runs only in the PC environment would help in
protecting people from trojan horses and viruses.
In the absence of a Ken Thompson modified compiler, building programs
from source has advantages.
First, users can customize it (see firewall discussion in referenced
articles above) for the local environment. [ Even if you just
supplied .o files this is possible to a certain extent, though in the
world of PCs not all compilers are going to be compatible. ]
Second, <em>after</em> a problem is detected, it is much easier to
discover the potential extent of the damage via source code inspection
rather than hand disassembly. Sometimes damage could even be caused
by simple bugs, not viruses or trojan horses. Perhaps having the
sources didn't help with protecting the user from damage, but it will
help with damage control and repairs.
The user of the code don't even need to keep the sources on-line for
post mortem diagnosis -- tape archives suffice. Note that it helps to
have source even if attackers deliberately obfuscated the code. After
all, analysis could always fall back to disassembly. Granted, the
source <em>could</em> be written to be misleading (in non-obvious
ways) somebody doing a source walk-through, but that increases the
effort on the attackers' part, which is all for the best anyway.
-bsy
--
Bennet S. Yee Phone: +1 412 268-7571 Email: bs...@cs.cmu.edu
CS Dept, SCS, Carnegie Mellon, 5000 Forbes Ave, Pittsburgh, PA 15213-3891
Gerald Edgar
If NCSA is concerned about people selling NCSA products for a profit, them maybe
you should do what the Pittsberg Supercomputer Center does- copyright the program.
You could still give it away (after all it does belog to NCSA), but it is no
longer public domain. Phil Andrews has brought up this topic to NCSA people at a
meeting some time ago.
Gerald Edgar
"The opinions expressed in this note may not reflect those of my employer"
Marc Andreessen
There are lots of factors involved, many of which obviously make it
desirable to release source -- but some of which may not. All I'm
saying in my previous msg is why it was obvious whether or not to
release the X source, and as quickly as possible.
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
ma...@ncsa.uiuc.edu
Chris Wilson
>: Distributing the source files is a major headache from our point of view
>: because it entails a large additional support requirement. There was
>
> Then stick a disclaimer in the archive and tell anyone asking questions
>to 'shove off' - "We are willing to support this binary, but we will not
>in any way support the sources or any derivatives of this product - We
>will also not apply diffs or accept the donated work of the many people
>out on the networks that would be willing to add features to our products
>for free" <half grin>.
AAAAARRRRRGGGGGGGHHHHHHH!!!!! This does not WORK!! we are still going to
get phone calls from people who "just have one quick question", or can't
get the source to compile, and want help getting set up. Also, accepting
donated work and diffs is one of the reasons we WOULD release source. I'm
guessing you're just being facetious, but in case you aren't or anyone else
didn't pick up on it, there you have it.
There is simply NO WAY around the fact that releasing the source to such a
major project is going to require a very large commitment of resources to
support on our (NCSA's) part. We do not currently have the resources to
get more tech support personnel, and the personnel we have are heavily
overworked. So, for those of you who now think we are money-grubbing
scum based on posts that _I_ (personally) made (which had disclaimers slapped
ALL over it), think again. We need more resources ourselves to be able to
provide more resources to our user community, and contrary to what some
people think, we are not fully funded by the government.
Once again, this post states MY OPINION, not NCSA policy. I am not a
spokesperson or representative of NCSA, and I should not be regarded as such.
-Chris Wilson
cwi...@ncsa.uiuc.edu
BTW, our mail seems to be pretty screwed up at the moment, so mail to me may
bounce or not be delivered. I will also be at SIGGRAPH for the remainder
of the week (through Sunday), so my responses will be spotty.
Chris Wilson
>I'm arguing that there are several advantages to at least
>additionally distributing source code, one of which is security,
>specifically prevention of virus and trojan horse distribution.
I don't think any of us are arguing that there are NO advantages to releasing
source code. However, your argument is that in the specific case of
Martin-Marietta, availability of source code would help assure there are
no viruses or trojan horses in our product. Fine. I'll let that by for the
moment. HOWEVER: you are opening up Mosaic to FAR more risk of having trojan
horses by letting everyone and their dog at the source - any random hacker,
knowing how popular Mosaic is, could download the source, hide a horse, and
upload the binary to their local BBS. Now, you say (or have said, in essence),
whoever downloads this is at fault, because they didn't get Mosaic from the
official distribution site (NCSA's FTP server). HOWEVER, I say it is
ridiculous to assume that everyone has A) access to NCSA's server, and B)
FAST access to NCSA's server. People in Switzerland would probably prefer
to get it from CERN, for example. "archie -s xmosaic" returns 31 sites
with NCSA Mosaic for XWindows. Most if not all of them have binaries.
Anyone seeing xmosaic on one of these sites is probably going to assume
that these are NCSA-compiled and NCSA-supported binaries. (I am speaking
of Joe User, here, not security managers at sites where security is a major
issue.) I am not saying that you have no point WRT THs and viruses - just
that you are, at the same time, creating potential problems for the majority
of our user base.
>bjac...@mentor.cc.purdue.edu (Ben Jackson) writes:
>>Which is to say you read all the code you compile? I think not.
>
>Whether I do or not is irrelevant. Our company's security policy wisely
>prohibits installation of precompiled binaries for free software. I say
>"wisely" for reasons I've already explained.
*BZZZT* Wrong. It most certainly is NOT irrelevant. If you're not using
it, why do you need it?
>>Being able to recompile might protect you from viruses, but it's
>>certainly not protection from "malicious code".
>
>It's not sufficient to protect against malicious code, but it's
>necessary.
Huh? Why?
>>>>If this is the case, I'm sure we
>>>>hide a few trojan horses in our code that you probably wouldn't see -
>>
>>>>That's about as funny as joking about having a bomb in your suitcase while
>>>you're going through airport security.
>>
>>I'm sure Chris will correct me if I'm wrong, but I don't think it was a
>>joke.
>
>You're asserting that NCSA hides trojan horses in their code?
No, that it would be POSSIBLE for me to do so. Sorry, there was supposed to
have been a "could" at the end of my first line there...
>>The point is YOU DON'T READ THE SOURCE! You may skim a few files,
>>but if someone wanted to trojan you, the only protection you have is to
>>NOT USE THE PRODUCT.
>
>No, the point is IF YOU CAN'T GUARANTEE YOUR PROGRAM IS SAFE, AND YOU
>WON'T LET ME CHECK IT, I CAN'T RUN IT!
My response to that is you inferred above that you wouldn't even check
through all of it. If this is the case, why bother to do a half-hearted
check at all?
>The developer loses, too, when people can't run his application.
Won't. Regardless, I don't consider myself losing out because I am not
writing an OS/2 version of Mosaic, because I think my time is vastly better
spent working on creating a better product for the larger Windows user
base. See the analogy?
-Chris Wilson
cwi...@ncsa.uiuc.edu
This is my opinion, not NCSA's. I am not a spokesperson for NCSA.
Chris Wilson
I have to applaud. Once again, I also am in favor of source code distribution.
(If you don't believe me, look on NCSA's FTP server for some of my source
code that I have released.) And again, the decision about whether to release
source or not has not been reached at NCSA.
-Chris Wilson
cwi...@ncsa.uiuc.edu
Tom Griest
I would like to see the source distributed. One of the attractions to
Mosaic was that the sources ARE being released. To not release them
with the Windows version seems like the X version was just a "teaser". :-(
There have been several legitimate needs mentioned for release of the source,
and if the burden of questions related to the source is believed to be
too high, then I think most asking for the source would accept it with
a no-questions asked policy. If need be, there could be a network-based
support group for those using the source and wishing to share
problems/solutions. Any "source-code question" mail directed to NCSA
could have a standard reply to rtfm. As long as it is CLEARLY stated up
front that there is no support for source code problems, people
will understand.
-Tom
Marc Andreessen
(Tom Griest) writes:
There have been several legitimate needs mentioned for release of
the source, and if the burden of questions related to the source is
believed to be too high, then I think most asking for the source
would accept it with a no-questions asked policy. If need be,
there could be a network-based support group for those using the
source and wishing to share problems/solutions. Any "source-code
question" mail directed to NCSA could have a standard reply to
rtfm. As long as it is CLEARLY stated up front that there is no
support for source code problems, people will understand.
Some will. Many won't.
Releasing source is, practically speaking, equivalent to saying "We'll
support it, answer your questions, hold your hand while you try to
compile it, merge in any fixes or changes you send us, whatever"; if
we don't follow through, people will get upset. I am not
hypothesizing here. As for a generic warning label, people will read
it and then figure it doesn't apply to them and get upset anyway.
This is not as simple a situation as you may believe it to be. Please
be patient and understanding; we're working on it.
HALLAM-BAKER Phillip
I really can't see why people are so keen to hassle Marc over the source
issue. There are often very good resons why source cannot be released.
In the case of BILBO, a system I built the sources cannot be released because
they are not in a conventional language, they are all written in languages
designed on a one off basis. Unless you have the synthesizer you simply
cannot compile them. Since the synth is currently only supported running on
VMS using a large number of pretty expensive software products there is
no way that real source can be released unless the synths are as well. Since
I am currently trying to sell one of them there are good resons why the
source is not likely to arrive either.
I could of course release the intermediate code which is ANSI C. However
from these it is quite easy to reverse engineer the synth which is a
valuable property. Also there is the danger that people will patch the
source to extend the functionality which then means that all the benefits
of using the synth (maintainability, validation) are lost.
Regardless of what NCSA do there will certainly be at least one Windows
browser in the public domain with source avaliable. Browsers are like busses,
you don't see any at all for weeks then five come at once. For quite a while
we had browsers for almost everything except for X-Windows. Then we got
Tk-WWW, Cello and Mosaic amongst others.
If people are good enough to let others use their code then those that
benefit from it should recognise that they are being done a favour. There
are problems arround viruses etc that exist with binary only distribution,
however these can be overcome. If people desperately need a browser that
they have full control over then the easiest solution is to take the common
code and write one. It really is not a big job. Most of the work is done
for you in libwww. Even the extensions in Mosaic such as images can be accesed
if you take the X-11 mosaic dist, one day they should be in the CERN dist.
The hard part is understanding the common code - I wrote a browser specifically
to do that, its almost certainly the easiest way at the moment (this will
change!!!)
Phill Hallam-Baker
Erik Ostrom
> Releasing source is, practically speaking, equivalent to saying "We'll
> support it, answer your questions, hold your hand while you try to
> compile it, merge in any fixes or changes you send us, whatever"; if
> we don't follow through, people will get upset. I am not
> hypothesizing here. As for a generic warning label, people will read
> it and then figure it doesn't apply to them and get upset anyway.
Perhaps those who insist on source code availability for the Windows
version of Mosaic should volunteer to provide support, answer questions,
and hold people's hands. (Merging in changes might be a little too much
to expect.) Set up a mailing list that points to these people; make it
clear that they, not the NCSA developers, have to deal with the support
problems they appear not to believe in; let them cope.
Or perhaps not.
David Will
IMHO- Although the values and problems with source code should be
freely discussed, I think it is should be recognized that the products do belong
to NCSA and they should be the final arbiter of what is feasible to release,
what is feasible to support. Releasing a piece of freeware/shareware does not
and should not imply support forever or even now. As a recipient of the
hard work of others I am always grateful. I do not wish to inhibit the
production of software by insisting on particular modes or methods of
distribution.
I do appreciate support and I do think that availibilty of source code can
enhance the growth of an application, but it is not a prerequisite and it is
useless if for every 5 products produces 200 stay hidden away on the systems
of the developers because of the fear of overwhelming support requests or the
loss of their ideas to the public domain.
------------------------------------------------------------
David Will wi...@physunc.phy.uc.edu (513) 541-8421
The Ascalon Group.
Systems Integration, Internetworking, Database Design, and Progamming
for Open Systems, OS/400, and DOS/Windows.
Tom Griest
>Releasing source is, practically speaking, equivalent to saying "We'll
>support it, answer your questions, hold your hand while you try to
>compile it, merge in any fixes or changes you send us, whatever"; if
>we don't follow through, people will get upset. I am not
>hypothesizing here. As for a generic warning label, people will read
>it and then figure it doesn't apply to them and get upset anyway.
This is where I think the confusion is. I know of many sources that
are released that DO NOT have any support. I would think that you
could set up a specific account for mosaic-windows-source-support
that simply logs the message (for future use if you so desire) and
acknowledges with a message that there is currently no source-code
support effort. Electronic mail is very easy to trash.
If there is some other reason not to release the source (like you want
to start selling the program), that's a different story. Some people
don't want to start using Mosaic until they know that they can get
problems resolved if need be. The only way to be sure that they can
resolve the problems is to have the source, and be prepared to fix
the problems themselves. For example, I might not want to promote
use of Mosaic in the local high-schools unless I am confident that I
can get (local) problems resolved (like being able to filter material).
Once a great deal of time/effort has been expended on Mosaic we then
become dependent on NCSA. Having the source (assuming we evaluate
it and determine that it can be modified locally) provides a backup
position that gives the confidence necessary to encourage its use.
>
>This is not as simple a situation as you may believe it to be. Please
>be patient and understanding; we're working on it.
>
Does this mean that the question is just a matter of WHEN and not IF
the sources for Windows-Mosaic will be available? Last I had heard,
it was still questionable if they would ever be released.
-Tom
Standard Disclaimer: I speak for myself only.
Marc Andreessen
hal...@dxal18.cern.ch (HALLAM-BAKER Phillip) writes:
... the easiest solution is to take the common code and write one.
It really is not a big job.
Wheeeeeeeeeeeeeeeeeeeeeheeheeheeheeheeheeheeheeheeheeheeeeeee.
Dave Sill
>In article <1993Jul27.1...@ornl.gov> d...@ORNL.GOV (Dave Sill) writes:
>>
>>I'm arguing that there are several advantages to at least
>>additionally distributing source code, one of which is security,
>>specifically prevention of virus and trojan horse distribution.
>
>And as you admit later, source distribution prevents neither, although
>it conceivably could IF you scrutinized the source before compiling and
>installing it.
I admitted no such thing, it's entirely contrary to the point I'm making.
>Even if you took that step, someone who wanted to include
>a trojan horse in their code would probably be able to hide it.
It could be hidden, but could it be hidden successfully? How long?
>>>Which is to say you read all the code you compile? I think not.
>>
>>Whether I do or not is irrelevant. Our company's security policy wisely
>>prohibits installation of precompiled binaries for free software. I say
>>"wisely" for reasons I've already explained.
>
>It is NOT irrelevant.
It is irrelevant to the point that our policy doesn't allow us to run free
PC binaries downloaded via the net. It's irrelevant to the point that
even if we don't scrutinize the source, someone else might.
>Claiming that what I say is irrelevant, with no
>support for that argument, is just a cheezy tactic to avoid the issue.
No it's not, it's merely an attempt to keep from being (overly)
repetitious--I've already supported the argument in other articles.
>How does having the source protect you if you don't read it?
To repeat myself, again:
o it allows us to compile the code in a virus-free environment, and
o it opens the code to public scrutiny, making it vastly harder to
successfully and permanently hide malicious code.
>... the point is IT'S POSSIBLE to hide trojan horses in the source code.
Granted. It's possible, but *much* harder when the code is public.
>There are plenty of good reasons to distribute source, but yours is not
>one of them.
We clearly disagree.
>If the developers of Cello don't want to distribute source,
>that is their choice.
No problem. I can gripe about it, though, can't I?
>You are still faced with the same decision:
>use the binary or find another application.
That's a no-brainer...we have no choice.
Dave Sill
>... HOWEVER: you are opening up Mosaic to FAR more risk of having trojan
>horses by letting everyone and their dog at the source - any random hacker,
>knowing how popular Mosaic is, could download the source, hide a horse, and
>upload the binary to their local BBS.
Caveat emptor. NCSA's binaries are equally subject to adulteration once
they've left NCSA's server. The user is responsible for insuring that the
software he installs, whether source or binary, is as distributed. In the
UNIX world, checksums are one way of doing that. Another is to get it
directly from the source, no pun intended.
>>>Which is to say you read all the code you compile? I think not.
>>
>>Whether I do or not is irrelevant. Our company's security policy wisely
>>prohibits installation of precompiled binaries for free software. I say
>>"wisely" for reasons I've already explained.
>
>*BZZZT* Wrong. It most certainly is NOT irrelevant. If you're not using
>it, why do you need it?
Read what I've written, and try to see things from my point of view. I've
already explained several times why it's irrelevant.
>>>Being able to recompile might protect you from viruses, but it's
>>>certainly not protection from "malicious code".
>>
>>It's not sufficient to protect against malicious code, but it's
>>necessary.
>
>Huh?
Are you familiar with the concepts of necessary and sufficient conditions?
For example, the presence of oxygen is necessary for combustion to occur,
but not, in itself, sufficient to ensure that it will.
>Why?
Merely having the source is not sufficient to protect against malicious
code, but source code is necessary to protect against malicious code if you
take the following steps:
o scrutinize the source code for included malicious code, and
o compile the source code in a virus-free environment.
>>The developer loses, too, when people can't run his application.
>
>Won't.
No, "can't". The end-user here *can not* run free PC binaries obtained via
the net.
>Regardless, I don't consider myself losing out because I am not
>writing an OS/2 version of Mosaic, because I think my time is vastly better
>spent working on creating a better product for the larger Windows user
>base. See the analogy?
No.
Dave Sill
>
>If people are good enough to let others use their code then those that
>benefit from it should recognise that they are being done a favour.
I greatly appreciate NCSA's efforts. I'm something of a Mosaic evangelist
around, here. At least an *X* Mosaic evangelist. I'm not a PC user, but I
can't even recommend free PC software that's only available as precompiled
binaries FTP'able from the net. Pardon me if I'm looking NCSA's gift horse
in the mouth, but I think they ought to when their potential users have
problems with their software.
Dave Sill
>benefit from it should recognise that they are being done a favour.
I greatly appreciate NCSA's efforts. I'm something of a Mosaic evangelist
around, here. At least an *X* Mosaic evangelist. I'm not a PC user, but I
can't even recommend free PC software that's only available as precompiled
binaries FTP'able from the net. Pardon me if I'm looking NCSA's gift horse
in the mouth, but I think they ought to when their potential users have
problems with their software.
--
Dave Sill
>
>When I was but a wee lad, ...
>
>["fairness" homily deleted.]
Yeah, how naive of me to expect something as unguaranteed as fairness. What
was I thinking?
>I do, by the way, feel sorry for you that acquiring a purchase order,
>etc. at Martin Marietta appears to be such a difficult and demanding
>task, particularly as it must get awfully cold in your hand-made
>thatched-roof mud huts in the winter.
Yuk, yuk, Marc. When can I catch you on the Improv?
I think this might be the straw that broke the camel's back...
Up until this issue came up, I was a vocal proponent of Mosaic, and thought
pretty highly of developers. The abuse I've taken here and total lack of
sympathy on the part of those developers has erased any feelings of good
will I (apparently undeservedly) held for them. I'll continue to use X
Mosaic (as long as I have source), but my days of preaching its virtues are
over.
BTW, if you're a Mosaic fan, check out tkWWW.
Dave Sill
>
>Mr. Sill then posted a provocative post stating that if we didn't release our
>source that he would be unable to use it because he couldn't be sure that we
>didn't include a virus.
No, because our company-wide security policy forbids it.
>Since that point Mr. Sill has consistently
>misrepresented our statements
Not intentionally, and I challenge you to provide an example!
>and basically offended our sensibilities.
Again, I made it clear that our security policies were designed to ensure a
safe computing environment, and that you shouldn't take them personally.
>... Mr. Sill has simply whined
>and said the we aren't being "fair" while stating that since we haven't
>had security checks that we cannot be trusted.
Oh, I get it. When users don't shower NCSA with praise for their
beneficence in providing Mosaic free-of-charge, it's "whining". Or, if
it's the persistent, repetitious nature of my postings that constitutes
"whining", they were made necessary by your apparent inability to
understand my predicament and arguments.
Talk about misrepresentation: I never said that "since [NCSA] haven't had
security checks that [they] cannot be trusted". I *did* say that we, the
users, have seen no evidence of security measures taken by NCSA to ensure
that the code they distribute is safe. I don't know if you have good
security or not, and would never claim that you don't without evidence.
>I, however, could care less if Mr. Sill ever uses my product.
Likewise.
>... The policy in
>regards to source release is entirely the choice of NCSA and those who
>provide our funding. If you do not fall into either of those categories you
>are more than welcome to present suggestions and rationale. You are not,
>however, in a position to dictate that decision.
Duh. I never demanded anything except that my arguments be seriously
considered.
>... If your corporate policy
>does not allow you to use a product which is produced by a reputable
>government affiliated agency simply because they are GIVING IT AWAY instead
>of selling it then I suggest that your policy is in fault.
"government affiliated"? Hmm, that implies "government funded", at least
partially. Making me, a U.S. taxpayer, one of those who funds NCSA.
Hence, I should have a voice in the decision on source distribution. I
certainly don't like to see my tax money funding development of code that I
can't get.
BTW, Jon, our policy has nothing against free software, including binaries.
But it does require that we take commonsense precautions to ensure their
safety.
>Mosaic is a
>product which could very easily have been sold commercially.
Although heavily based on free code and taxpayer-subsidized.
>I find it frustrating that people like Mr. Sill don't realize the bargain
>that they are getting and choose instead to criticise us.
And I find it frustrating that people like Mr. Mittelhauser think they can
do whatever pleases them merely because they don't charge for some forms of
their product, which was developed partially at the expense of the
taxpayer.
Are all of the Mosaic developers as arrogant as you?
Chuck Shotton
"flame" against any individual. I have followed this thread for the last
couple of weeks, hand have been absolutely astounded by the idiocy of it.
Here's my two cents' worth:
In article <1993Aug6.1...@ornl.gov>, d...@ORNL.GOV (Dave Sill)
wrote:
> In article <1993Aug3.0...@dxcern.cern.ch>, hal...@dxal18.cern.ch (HALLAM-BAKER Phillip) writes:
> >
> >If people are good enough to let others use their code then those that
> >benefit from it should recognise that they are being done a favour.
It is not that they are being "done a favour." Users need to recognize that
there is NO fundamental difference in a piece of software that comes from a
large, reputable academic institution's development organization and one
that may come from tiny, garage based shrink-wrapped software company, save
one. In many cases, the software from the former is available at no charge
while the latter often charges more than the software is worth.
It is certainly the case that many universities and research institutions
have development staff, policies, procedures, tools, and techniques for
developing software that rival the QUALITY of anything available in the
commercial marketplace. (NCSA's software generally falls into this
category, but that's not the main point here.) These institutions often
choose to make these programs available to the general internet community
in the spirit of free exchange of information.
The people who are whining for source code to "free" software give all
sorts of arguments about corporate policies, fear of trojan horses,
viruses, etc. These are certainly the concerns of a responsible system
manager but they have NO bearing on the kinds of software associated with
WWW and institutions such as NCSA. First, software distributed from known,
reputable sources over the net is fundamentally no different that software
distributed from known, reputable sources on floppies (perhaps inside some
shrink wrap?). If you think so, please explain why bits dragged in through
your ethernet port from a read-only source are any less reliable than bits
loaded in via the read/write head on your floppy drive. If there is a virus
or Trojan horse, you know EXACTLY where it came from if you are dealing
with binaries from a reputable archive. This is ample incentive for these
institutions to ensure that none exist in the products they release.
Having the source and distributing homemade binaries actually complicates
the issue, as disgruntled employees at YOUR site can make changes to the
source and release trojan laden versions from in-house. Also, you have to
be worried about the viral state of multiple machines at your site and the
effect on your development boxes, rather than accepting a single virus-free
binary from a reputable site.
Second, you certainly can't expect commercial companies like Microsoft to
distribute the source code to Microsoft Word with every PC or Mac binary
they distribute, just because you want to A) fix the bugs that may afflict
your users, B) identify trojan horses hidden by disgruntled MS employees,
or C) (and I expect this is the ROOT cause of all the whining) satisfy your
curiosity as to how the program works and/or take pieces of the source for
your own use.
If you accept the fact that large commercial development houses will not
distribute source because A) of profit reasons, B) to maintain
configuration control (the REAL issue in my book), C) users wouldn't know
what to do with 2 million lines of twisted C code on 50 floppies, how can
you expect large academic institutions to do the same?
Certainly, the lack of operating systems standards in the Unix world
necessitate the distribution of source code so binaries could be built,
which explains the tradition. But how often have you ever gotten the source
code to an application on a PC platform versus only the binaries, purchased
or not? Tradition is not a valid argument in this case, regardless of how
"curious" you might be to get a peek at the source code. As I mentioned, I
suspect that this is the real, underlying reason for 98% of the arguments
for distributing source code. People simply want to hack their own versions
and piggyback their own glory on someone else's hard work.
Nor is there a legitimate need for the source for "fixing bugs". I know
many people who have worked on large, complex applications can sympathize
with the problems associated with configuration control, incremental
changes and releases, and the general maintenance problem. Imagine the
nightmare that the folks at an institution like NCSA would have trying to
maintain the integrity, cohesiveness, and functionality of THEIR product
with half a million PC hackers whittling away at THEIR code. Imagine all of
the mutations and confusion among the user community when confronted with
"Bob's Better PC Mosaic", "University of BFE's Mosaic for Windows",
"mosaic", "NCSA Mosaic", etc.
In this respect, I would follow NCSA's actions and keep a tight rein on the
source code, just to minimize the impact on my in-house development staff.
Any capable institution will be able to make bug fixes and incorporate
changes and enhancements just as fast as a commercial company. You don't
beat on Microsoft for source to fix their bugs, so that argument doesn't
hold here for "free" software either. The case has been amply made in other
messages that most people wouldn't know what they were looking at or
actually take the time to do a line by line analysis of source if they had
it. So, I am forced to go back to the "curiosity" reason as the major
motivator here. You don't really have a NEED for the source code, you just
WANT it.
> I greatly appreciate NCSA's efforts. I'm something of a Mosaic evangelist
> around, here. At least an *X* Mosaic evangelist. I'm not a PC user, but I
> can't even recommend free PC software that's only available as precompiled
> binaries FTP'able from the net. Pardon me if I'm looking NCSA's gift horse
> in the mouth, but I think they ought to when their potential users have
> problems with their software.
It is simply the case that you are taking an extremely naive view of
software available on the net and lumping all binaries distributed without
source in one pile and all applications distributed as source in another
without regard for the origination of the program. There are several
examples of COMMERCIAL software distributed WITHOUT source code via the net
in binary form only. Intercon is one such company that distributes the code
and mails you the serial number key. I defy you to show me a difference
between this binary code available from ftp.intercon.com and the Mosaic
binaries available from ftp.ncsa.uiuc.edu. Or is it the case that you
wouldn't use Intercon's software either? (In which case, you'd better
remove everything from your hard disk that you don't have source code for.)
-----------------------------------------------------------------------
Chuck Shotton
csho...@oac.hsc.uth.tmc.edu "I am NOT here."
John Franks
>... C) (and I expect this is the ROOT cause of all the whining) satisfy your
>curiosity as to how the program works and/or take pieces of the source for
>your own use.
> So, I am forced to go back to the "curiosity" reason as the major
>motivator here. You don't really have a NEED for the source code, you just
>WANT it.
>
I find this offensively condescending. Why shouldn't someone want to
learn how to write sophisticated graphics/network software. You make
it sound like they are voyeurs. Helping create the next generation
of programers may not be part of NCSA's mission, but it is something
they could be proud of.
Some general thoughts on this thread:
1. Security: Security is better with source, but security with a
binary from NCSA is adequate for most reasonable purposes. However,
some institutions have policies against binary only free software.
These may be irrational policies, but they exist and are unlikely to
change. One of NCSA's objectives is to have their software used.
Not releasing source will have a negative effect on that objective,
but probably not a large one.
2. Bugs/quality: Based on personal experience in the UNIX world, I
have no doubt that available source means bugs get fixed much
faster and in many cases bugs get fixed that wouldn't be fixed
if source wasn't available. There are many examples one can point
to of enhanced features that wouldn't exist if source weren't
available.
3. Support requirements: If binary and sources are available I would
guess that 95% of users would only get the binary. I suspect this
is currently true for Xmosaic. The 5% who get source will be of
a variety of sorts: budding programers who want to learn, sysadmins
complying with a company policy, sysadmins wanting to try to fix a
bug, etc., but it will be a relatively small group. If they badger the
developers, just say *no*. A response of "get the binary it works fine,"
is completely adequate.
4. Version control: Things like "Bob's better mosaic" are very unlikely
to happen. We don't have "Bob's better perl" or "Bob's better gcc."
The only instance I can think of where there are variants is emacs and
there the variants are serious valuable programs meeting a need and
in no way threatening the integrity of GNU emacs. There is a good
reason the variants are scarce. If I find and fix a bug in free
software, I am strongly motivated to help the developers fix that
bug, because I know there will be new releases with enhanced features
and I don't want to have to install my fix again and again.
John Franks Dept of Math. Northwestern University
jo...@math.nwu.edu
Reinhard Doelz
I am working in the molecular biology sector for a long time now. There's
a couple of software products around, as Public Domain, with and without
source, and most this software never quite made it to be widely accepted.
It is because of the limited support of system X with extension Y in the
special configuration Z which always makes a small hack neded, and the
binary will be trashed from the beginning, and the source - well, there
are a few communities out there who really help guys out on their own,
but it isn't real fun to see so many desparate end users claiming that
it works and one speaks up and tells that it never worked for him.
There's another aspect - PD software usually covers the features of interest
at the provider's lab. Depending on the scope, this might or (more
frequently) might not represent what is the typical lab in the field.
This means that some of the applications might be quite OK but the
niche aspect person X is working on in Y wasn't considered in the
software author's lab. If X is now a non-programmer, and has no resources
at Y, who is going to write the missing part? It is rather 'bad' software
instead, and reviewed as such, because some aspects are not filled.
I have been involved in writing software myself. I develop a protocol
which is basically a RJE but on semi-anonymous basis. As I am about
releasing version 4, I have had already three design cycles where I had
the opportunity to get feedback from my sites who all have the source.
From the developer's point of view, very disappointing features are:
o Very few take the time to step beyond a failed 'make' - they just trash it.
o If someone makes a hack to get it going in his/her specific environment
it is usually so badly explained that I cannot incorporate it into
a release - and I cannot check it out as I usually have no access
to this configuration.
o The sites where I install it personally are very satisfied (that is part
of my businesss) but the end-users usually don't appreciate it -
Use and abuse it the theme of the game.
o System managers occasionally get me extremely valuable feedback in terms
of security and integrity. However, the suggestions made take
a couple of man-months to get implemented, and I cannot spend that
many resources.
o The number of systems is permanently increasing. In 1988, I needed to
support 4 operating systems and this was it. Today it is 6, but
with 3 different patch levels/versions/environments each on average.
Giving away source just makes people think that you should support
even more. Who's gonna _pay_ me for this if I have only 20% of
the systems supported in-house?
o Nearly no one comments on strategic issues. Nut-pickers are frequent,
and very little gets through in terms of real good suggestions -
forgive my ignorance but I am afraid that this expresses the feeling
mentioned earlier in this thread - people don't need the source
but they just WANT it.
As I am a state employer, I can't sell the source. However, from the
results I had so far, exposing source is a break-even business at best.
My 0.05 SFr. on this topic.
--
+----------------------------------+-------------------------------------+
| Dr. Reinhard Doelz | RFC do...@urz.unibas.ch |
| Biocomputing | DECNET 20579::48130::doelz |
|Biozentrum der Universitaet | X25 022846211142036::doelz |
| Klingelbergstrasse 70 | FAX x41 61 261- 6760 or 267- 2078
| CH 4056 Basel | TEL x41 61 267- 2076 or 2247 |
+------------- bioftp.unibas.ch is the SWISS EMBnet node ----------------+
ftp mirror at nic.switch.ch
-----------------------------------------
Marc Andreessen
writes:
BTW, if you're a Mosaic fan, check out tkWWW.
Indeed! And Midas 2, when Tony Johnson releases it -- it's looking
really nice.
Marc Andreessen
Weaverling) writes:
How about D) You need source code because binaries for your machines
aren't available. I don't see any binaries for 88100 machines out there...
Or do we throw the idea of open environments out the window and let
the market decide on a "<insert vendor> compatible" architecture like
the PC world has and let one vendor control the market?
It already seems to me that the "net" is deciding for me that I should
only by a Sun, DEC, or SGI machine otherwise I am SOL...
Huh? The discussion into which you are coming has been about Intel
PC/Microsoft Windows binaries, not Unix binaries. Mosaic for X and
every other X browser out there (that I know of) ships with source.
Benjamin Z. Goldsteen
>FIRST, let me preface the following by saying that this is not a personal
>"flame" against any individual. I have followed this thread for the last
>couple of weeks, hand have been absolutely astounded by the idiocy of it.
>Here's my two cents' worth:
>It is certainly the case that many universities and research institutions
>have development staff, policies, procedures, tools, and techniques for
>developing software that rival the QUALITY of anything available in the
>commercial marketplace. (NCSA's software generally falls into this
>category, but that's not the main point here.) These institutions often
>choose to make these programs available to the general internet community
>in the spirit of free exchange of information.
>The people who are whining for source code to "free" software give all
>sorts of arguments about corporate policies, fear of trojan horses,
>viruses, etc. These are certainly the concerns of a responsible system
>manager but they have NO bearing on the kinds of software associated with
>WWW and institutions such as NCSA. First, software distributed from known,
>reputable sources over the net is fundamentally no different that software
>distributed from known, reputable sources on floppies (perhaps inside some
>shrink wrap?). If you think so, please explain why bits dragged in through
>your ethernet port from a read-only source are any less reliable than bits
>loaded in via the read/write head on your floppy drive. If there is a virus
>or Trojan horse, you know EXACTLY where it came from if you are dealing
>with binaries from a reputable archive. This is ample incentive for these
>institutions to ensure that none exist in the products they release.
>Second, you certainly can't expect commercial companies like Microsoft to
>distribute the source code to Microsoft Word with every PC or Mac binary
>they distribute, just because you want to A) fix the bugs that may afflict
>your users, B) identify trojan horses hidden by disgruntled MS employees,
>or C) (and I expect this is the ROOT cause of all the whining) satisfy your
>curiosity as to how the program works and/or take pieces of the source for
>your own use.
Although I have no real need for source to PC Mosaic, I would just
like to make a few corrections. NCSA software is pretty good, but I
hardly call it bug free. I like it; I use it; I have been bitten a few
times.
Case in point would be NCSA Telnet for the Mac. There are a few
bugs in it -- one dealing with large fonts, another is a ~ left behind
in in this one application, and a few things related to passing of the
terminal type, keyboard mappings, etc. I sent an e-mail to NCSA about
the large font problem (12-point is not big enough for me) and I got an
e-mail back like a WEEK OR TWO LATER that was merely an ACK of my
complaint and that they were forwarding my message to the developers.
I am not sure if I could fix the font problem (I am not knowledgeable
about Mac programming), but I could fix the passing of the terminal
type and keyboard mappings because NCSA releases the source.
These problems prevent us from using NCSA Telnet -- instead we are
using VersaTerm PRO (D200 emulation -- really we have this old DG
MV/9500 Eclipse -- and people use for Word Processing!) and recently
Intercon's TCPconnect (of which I once made a passing complaint in a
USENET group and was contacted by the manager of the project who had
one of his programmers contact me like the SAME day [the bug was that I
was trying to use it in a way that did not want, but they had not
completely shut the door]).
One theme I have noticed in public-domain software is that there
is often not the level of configuration as with commercial products --
a configuration interface that contemplates all the possible needs of a
user and site is a time consuming and tedious portion of an
application. The availability of source code means that I can adapt it
to our site (Gram's Command for UNIX wanted to store the default global
configuration files in / -- a few change and it was in /usr/local/lib
[setting the default configuration file location is often difficult to
do in a configuration file too :-)]).
This is not to knock NCSA -- their software is good (I think their
PC Telnet is one of the finest available for DOS) and innovative, but
they are a research institution. They do not have time or money to
create support staffs and keep with a product after it is reasonably
done. They must move onto to new ideas (Telnet is great but hardly
revolutionary). In general, I would rather see NCSA release the source
and move on to new things than try to support old (but necessary)
software indefinitely.
--
Benjamin Z. Goldsteen
Richard W. Wiggins
writes:
I think Dr. Franks makes very good arguments. The belief seems to be
that in the PC environment releasing source leads to a different kind
of support issues -- maybe simply because there are so many more PCs
out there, and so many variants of TCP/IP hardware and software to
worry about, the fear is that the support burden actually increases
with source available.
If it is true that releasing source for the PC platform leads to higher
support costs, then it seems to me the suggestion in an earlier posting
is absolutely right on the mark: Simply charge a fee for the source.
Start at a reasonably low number -- $100 per year or something.
Keep raising the fee until it lowers the support burden, or until
it brings in enough money to pay for the support!
Whatever you do, please don't begin releasing the source, then stop
doing it. That's what U Minn did with PC Gopher. We needed source
to make it work in our environment. Even though U Mn now has fixed
the client, the timing was such that we decided to use another client.
/Rich Wiggins, Gopher Coordinator, Michigan State U