[comp.unix.ultrix] phew!

smaug@eng.umd.edu (Kurt Lidl) (04/07/90)

In article <10655@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes:
>
>Some kind of "License Management Facility" (arghh!)

You got that right!!
Why does the ugly spectre of VMS licensing agreements have to
rear it head in U*ix?  I want a nice little (?) operating system
that will just run the damn code that I put on it, without
seeing how many "users" are logged into the machine and so forth.

>Inclusion of both Kerebos and Hesiod security stuff.

Good.  Now -- are they still shipping systems with /dev/kmem world
readable?
							-Kurt
--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */

amichiel@rodan.acs.syr.edu (Allen J Michielsen) (04/07/90)

In article <1990Apr7.081638.1374@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes:
>Why does the ugly spectre of VMS licensing agreements have to
>rear it head in U*ix?  I want a nice little (?) operating system
>that will just run the damn code that I put on it, without
>seeing how many "users" are logged into the machine and so forth.
>
 
   Sorry, I sorta disagree strongly.  I see what you are trying to say, etc,
but there are other considerations.  I see & talk to every day many many
individuals & companies from all walks of life, that think nothing of the
value of software products.  They don't even think twice before stealing 
software for anything from anyone.  The roll over & die or scream & whine 
like a stuck pig when they hear the price of software products.  It seems
the more something costs the more willing they are to steal it.
    The real problem compounds from here.  If I make a good software product,
and intend to charge a reasonable price for it, so that I can provide support
etc.  I have to have every system that runs it, pay for it.  If I have
stolen software, I have to charge more to every honest person to pay for
the stolen copies.
   I am not saying that you are a crook, the I recognize the fact that many 
many many people are.  I see system after system that the people are kinda
stuck at old system versions because all the software they have is stolen.
(& the new systems have license managers)  These same people are the ones that
are always calling me with stupid questions that would, could, & should be
answered quite quickly just by cracking the stupid manual.  Since the software
is stolen of course the manuals don't exist.
   While I dislike some of the features of the current generation of dec 
license managers, it does accomplish it's job fairly well.  I have spent less
than an hour total in over a year using it.  This is on a academic system that
has had several generations of temp paks, variance paks, & permament paks for
many different software products from several different vendors.  At the
user level, all they do, is run their stupid bits of code (to repeat your
french).  When the license manager keeps you from running your stupid bits of
code, either it's a very temporary situation (my experiences are that dec is
very helpful with pak #'s via phone as are all better vendors), or your system
manager needs replacing, else you are trying to steal software.  If you have
problem a. a little patience is all that's required, if it problem b. you have
a employee problem & shouldn't blame your software vendor, if it's problem c.
I have no pity at all for crooks.
   I for one applaud DEC and all other software vendors that provide trouble
free theft protection for their products.  In my experience, dec's license 
manager does just that.  This is akin to copy protection, companies that used
schemes that worked well (that didn't require constant stupid key disks or
limit the number or backups etc.) survived that holocaust well.
al

grr@cbmvax.commodore.com (George Robbins) (04/08/90)

In article <2834@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes:
> In article <1990Apr7.081638.1374@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes:
> >Why does the ugly spectre of VMS licensing agreements have to
> >rear it head in U*ix?  I want a nice little (?) operating system
> >that will just run the damn code that I put on it, without
> >seeing how many "users" are logged into the machine and so forth.
>  
>    Sorry, I sorta disagree strongly.  I see what you are trying to say, etc,
> but there are other considerations.  I see & talk to every day many many
> individuals & companies from all walks of life, that think nothing of the
> value of software products.

I don't mind an LMF facility when it encourages software vendors to go to a
simple dollars/session floating network license scheme.  I consider this much
better than some of the per CPU, price scaled by CPU or site license schemes
some software vendors play with now.

I think what a lot of Ultrix users object to more is the idea of DEC removing
yet more "standard BSD" features like pi, f77, franz lisp, and maybe cc and
replacing them with a set of expensive "layered products" with bizarre point
based license fees per the VMS world and a "license management system" to
serve as an "enforcer".

I'll be the first to admit that it costs money to port any of the Berkeley
languages to a new environment, but as a customer I see that as part of the
entry price of selling a BSD compatible system.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)

smaug@eng.umd.edu (Kurt Lidl) (04/08/90)

In article <2834@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes:
>In article <1990Apr7.081638.1374@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes:
>>Why does the ugly spectre of VMS licensing agreements have to
>>rear it head in U*ix?  I want a nice little (?) operating system
>>that will just run the damn code that I put on it, without
>>seeing how many "users" are logged into the machine and so forth.
> 
>   Sorry, I sorta disagree strongly.  I see what you are trying to say, etc,
>but there are other considerations.  I see & talk to every day many many
>individuals & companies from all walks of life, that think nothing of the
>value of software products.  They don't even think twice before stealing 
>software for anything from anyone.  They roll over & die or scream & whine 
>like a stuck pig when they hear the price of software products.  It seems
>the more something costs the more willing they are to steal it.

Hey, *everyone* is entitled to their opinions!

   I am not advocating stealing software.  I am talking about limiting
the productivitiy of a machine, because it will not let me log into
it more than twice, under the default system licensing.  The machine
in question -- a MicroVax II, with *no* console -- just a serial
line hooked up to a tty port on a SparcStation-1.
   I log into the uVax, and try to compile some of the C-News release on
it.  Something doesn't work.  So I login again in another window.
Fire up the editor.  I try to login again for access to the man
pages...  And the licensing system refuses to let me on, because
"two" users are already logged into the machine.  It is this basic
Operating System constrait that gets to me...
   I must be in a really special situation -- I don't care what a
package costs the University.  When someone drops a tape on my desk,
all I think is: How hard is it going to be to install it all and make
it work properly on our network?  The higher-ups in the University
are the people who care about the dollars and cents of each new
software package.  Not me.  I respect the time and effort that go
into making a good product.  However, I resent having to spend my
time covering for software writers who assume that "all systems
will be configured this way!"  I respect the needs of the companies
that write good software.  The companies that write bad software
and charge just as much are the ones that really irrate me.

>    The real problem compounds from here.  If I make a good software product,
>and intend to charge a reasonable price for it, so that I can provide support
>etc.  I have to have every system that runs it, pay for it.  If I have
>stolen software, I have to charge more to every honest person to pay for
>the stolen copies.

   Yes, I understand about high costs of writing and maintaining software
on multiple OS and hardware bases.  I understand that it takes
a lot of effort to come up with a product that is portable, reliable,
fast & efficient for so many different architectures.  We
try to develop and maintain software under 5 different architechtures
here where I work... It is not an easy job.  I know.
   I think that software development is a high-cost area, and will most
likely stay that way.  Some companies seem to make a lot of money
selling software in the source form, without excessive site licensing
agreements and so forth.

>   I am not saying that you are a crook, the I recognize the fact that many 
>many many people are.  I see system after system that the people are kinda
>stuck at old system versions because all the software they have is stolen.
>(& the new systems have license managers)  These same people are the ones that
>are always calling me with stupid questions that would, could, & should be
>answered quite quickly just by cracking the stupid manual.  Since the software
>is stolen of course the manuals don't exist.

   I personally think that a *lot* of the money spent on licensing
software should be folded into the production process way back in
the documentation stage...  I am *tired* of trying to install software
that has nearly undecipherable instructions for installation, and even
worse written documentation...  Even more frustrating is the software
that comes with a one-sheet that says:  "untar the tape into the
current directory with 'tar xvf /dev/nrst0' and then type 'install_me'".
  I almost always have to go through the installation script and
hand-tune sections of it to reflect our situation.  I have a *real*
dislike of having to human-interpret bourne shell commands to figure
out what a install script is going to do...  I have better things
to do with my time than massage a script written by someone who spent
twenty hours writing licensing checking code instead of writing a
decent README document for the software.

>When the license manager keeps you from running your stupid bits of
>code, either it's a very temporary situation (my experiences are that dec is
>very helpful with pak #'s via phone as are all better vendors), or your system
>manager needs replacing, else you are trying to steal software.  If you have
>problem a. a little patience is all that's required, if it problem b. you have
>a employee problem & shouldn't blame your software vendor, if it's problem c.
>I have no pity at all for crooks.

   Most of the "stupid bits of code" that I am interesting in running on
our Ultrix machines deal with being able to compile software (ie:
cc and friends) and being able to talk to the other machines on our
network, through various well-defined services...  Thus, I need to log
into a machine to compile -- Ultrix will not let me doe this more than twice.
Why?  I don't know.  All of our Suns will allow me to login as many
times as I want...
   Limiting the number of people who can access the C compiler on a U*ix
system is really quite alien to me.  Is there a real justification?
We are an academic installation.  We are trying to teach people how
to use computers to enhance their studies.  We are not trying to
abuse companies by installing their software into a hugh network
that violates their licensing agreement with the University.

>   I for one applaud DEC and all other software vendors that provide trouble
>free theft protection for their products.  In my experience, dec's license 
>manager does just that.

   This may be a "good way" of doing things for licensing software
products that are bought in addition to the basic U*ix platform, but
pretty horrible for the U*ix system itself.  I haven't seen any really
good license servers for a distributed network -- broadcast based servers
have a tendency to precipitate broadcast storms (at least from what
I can figure out from my readings and experience), file-locking ones
regularly fail in our multiple server configuration and so forth...

>This is akin to copy protection, companies that used
>schemes that worked well (that didn't require constant stupid key disks or
>limit the number or backups etc.) survived that holocaust well.

   Intelligent license managers for third-party products have a place.
I am not trying to argue that.  Buying a "ten user" license for a
network sits fine with me.  As long as it is reliable.  But this
doesn't sit well with me for the basic OS.

							-Kurt

Naturally, nothing that I say or think represents Official Policy
of the University of Maryland, College Park Campus.  They just pay
me to keep their network running, not to think :-)
--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */

rsk@boulder.Colorado.EDU (Rich Kulawiec) (04/08/90)

In article <1990Apr8.085237.3901@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes:
>...Even more frustrating is the software
>that comes with a one-sheet that says:  "untar the tape into the
>current directory with 'tar xvf /dev/nrst0' and then type 'install_me'".

Exactly.  I don't mind if one of set of installation instructions are
provided for naive installers who really *do* want the package to install
itself, and who don't care how/where it does it as long as it works when
they're done....but software distributors should provide a set of
installation instructions for those of us that know what we're doing.
(For example, the B news 2.11 installation instructions explain what
to customize, where to customize it, and what will happen as a result.
They're not perfect, but they're far better than the ones I received
with our copy of Saber-C. [ "tar..." followed by "RUN_ME" ]

One solution I've found to this is to run such scripts with -x and/or -v
turned on, and to run them as an ordinary user (not root).  By watching
why the install script really attempts to do, I can usually hack in the
changes I need much faster than hand-interpreting it.

---Rsk

sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (04/09/90)

In article <2834@rodan.acs.syr.edu>, amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes:
> 
>   Sorry, I sorta disagree strongly.  I see what you are trying to say, etc,
>but there are other considerations.  I see & talk to every day many many
>individuals & companies from all walks of life, that think nothing of the
>value of software products.  They don't even think twice before stealing 
>software for anything from anyone.  The roll over & die or scream & whine 
>like a stuck pig when they hear the price of software products.  It seems
>the more something costs the more willing they are to steal it.

I don't suppose you have scientific numbers on the thieves vs legitimate
owners? If you have 20-30% of the folks out there in The Real World who are
thieves, then you're screwed 70-80% of the legitimate purchasers who have to
deal with LMF. 

>    The real problem compounds from here.  If I make a good software product,
>and intend to charge a reasonable price for it, so that I can provide support
>etc.  I have to have every system that runs it, pay for it.  If I have
>stolen software, I have to charge more to every honest person to pay for
>the stolen copies.

False. You don't provide support to those people who have ripped you off.
Period. You buy a legitimate copy of a product, you pay for the distribution
and a license to use it. With Digital, you pay ADDITIONAL money for support (ie:
telephone hotline).

Digital's developmental costs are the same for quantity 1 or quantity
30,000.  

>   I am not saying that you are a crook, the I recognize the fact that many 
>many many people are.  I see system after system that the people are kinda
>stuck at old system versions because all the software they have is stolen.
>(& the new systems have license managers)  These same people are the ones that
>are always calling me with stupid questions that would, could, & should be
>answered quite quickly just by cracking the stupid manual.  Since the software
>is stolen of course the manuals don't exist.

So don't answer their questions. Encourage them to legitimately purchase
an upgrade and support. You are helping perpetrate piracy through aiding 
someone who has a "hot" copy.

>   While I dislike some of the features of the current generation of dec 
>license managers, it does accomplish it's job fairly well.  I have spent less
>than an hour total in over a year using it.  This is on a academic system that
>has had several generations of temp paks, variance paks, & permament paks for
>many different software products from several different vendors. 

Glad to hear it. I came into a situtation under VMS where the previous
system manager hadn't "followed the book" in using LMF, so I had to scramble
around for a day and a half to figure out what had been done. That also assumes
that you "know" and understand LMF. This costs time. Time is money. I don't
think DEC is going to reemburse me for the headaches I spent having to learn
their system. 

>  When the license manager keeps you from running your stupid bits of
>code, either it's a very temporary situation (my experiences are that dec is
>very helpful with pak #'s via phone as are all better vendors), or your system
>manager needs replacing, else you are trying to steal software.  If you have
>problem a. a little patience is all that's required, 

I guess you never have to deal with users face-to-face. "WHY CAN'T WE RUN
THIS NOW?" 

>if it problem b. you have
>a employee problem & shouldn't blame your software vendor, 

I should blame me for artificial constraints placed upon our system by
the LMF? Or my lack of understand of their way of using copy protection? 

>   I for one applaud DEC and all other software vendors that provide trouble
>free theft protection for their products.  In my experience, dec's license 
>manager does just that.  This is akin to copy protection, companies that used
>schemes that worked well (that didn't require constant stupid key disks or
>limit the number or backups etc.) survived that holocaust well.

As I understand it, Sun has managed quite well with granting unlimited
OS licenses with no copy protection. Not that Digital would want to copy
their policies.

In the microcomputer/PC world, the vast majority of companies which sell
software don't resort to such silly schemes today, having been pressured
to drop any semblance of protection. People who make a profit or do useful
work when using a particular software package find that it is much easier
to pay for the package (to get the documentation) and support, than to 
stay in the black hole of hotware. 

Besides, if you get caught, you'll get sued from here to tomorrow and
you WILL pay much much more in lawyer's fees than you would have in
purchasing legitimate copies of software.

rwood@dec.com (Richard Wood) (04/10/90)

In article <1990Apr7.081638.1374@eng.umd.edu>, smaug@eng.umd.edu (Kurt
Lidl) writes:
> In article <10655@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: 
> >Inclusion of both Kerebos and Hesiod security stuff.
> 
> Good.  Now -- are they still shipping systems with /dev/kmem world
> readable?
> 							-Kurt

ULTRIX v4.0 also includes NTP, since time synchronization is necessary
to keep the timestamp feature of kerberos (as well as other network
services) from getting messed.

ULTRIX v4.0 also includes the BSD kmem and tty groups.

Security can be set at several different levels, and includes features
such as long passwords, password aging, generated passwords,
kerberos/hesiod-based networked password database, etc.

-- ---------------------------------------------------------------------
Richard Wood     Corporate Worksystems Team      Digital Equipment Corp.
========================================================================

smaug@eng.umd.edu (Kurt Lidl) (04/14/90)

In article <937@granite.dec.com> rwood@dec.com (Richard Wood) writes:
>
>ULTRIX v4.0 also includes NTP, since time synchronization is necessary
>to keep the timestamp feature of kerberos (as well as other network
>services) from getting messed.

We've had NTP running on the Ultrix 3.1 machines here for quite
some time.  I don't think that this is such a great thing to selling
the system on.  Everybody who is doing lots of networking has
mostly adopted NTP across the board already.  Our Sun3s, Sparcs,
DecStations, Vaxen already do it.  I haven't given it a whack yet on
the RT's, but I don't think there will be any problems...

>ULTRIX v4.0 also includes the BSD kmem and tty groups.

This we have also done.  Mostly an exercise in changing permissions
on devices and files...

>Security can be set at several different levels, and includes features
>such as long passwords, password aging, generated passwords,
>kerberos/hesiod-based networked password database, etc.

Is the password aging a function of using kerberos or from some other
changes to the code.  Also, is there support for the BSD-style
"shadow" password scheme?

So I will ask again:
Did DEC fix the broken behaviour of /bin/sh on its machines?
Try getting the default "rn" compiled and installed and working.
I find that the /bin/sh scripts that it uses a lot (Pnews, Pnews.header,
Rnmail, etc) are a pretty good test of a machine's /bin/sh.
--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */