HDTenEightyP/NetNews huggingface dataset:
From: jlacour@casbah.acns.nwu.edu (John Lacour)
Subject: SCO Unix V/386 3.2.2 C2, Remove lines from /etc/passwd?
Followup-To: poster 
Organization: Northwestern University, Evanston, Illinois, USA
Distribution: na
Date: Wed, 23 Dec 1992 03:04:40 GMT

I have SCO Unix 3.2.2 installed w/ security enabled.  Id like to remove
entries from /etc/passwd.  Is it possible without screwing up the protected
databases?  I can easily disable the accounts, but there are several of them
and I'm someone who cares about aesthetics.

Please reply via email as I don't read this group often.

Thanks,
John
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: <None>
Date: 22 Dec 92 08:01:22 EST

In article <BzJK8L.6r0@NeoSoft.com>, claird@NeoSoft.com (Cameron Laird) writes:
> In article <1992Dec18.145952.26062@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
[...]
>>Let me start some new threads: WHEN should software be inspected?
1. Software should be inspected when the precursor material meets exit criteria
from its validation stage: complete DD, any planned simulations complete,
project management goals within bounds, lowest level decomposition elements
represented code sections within coding standards.  2. SW should be inspected
when there is 1:1 traceability between the design and existing code elements. 
3. When all selected code metrics are within bounds selected by team, or when
out of bounds values are explainable on the basis of code requirements. $. 
When the author believes it is ready.  4) On any Tuesday.  (8:-)).  Consider
these as ands.
>>Or: How many times should software be inspected prior to
>>initial delivery? 
Should be inspected until all major errors (those seen by the customer) are
below the project code exit criteria for Inspection.
>>Should software be inspected and put into
>>a configuration management system months before design is
>>complete and months before scheduled delivery, i.e., at a
>>Critical Design Review stage? 
To answer this requires more understanding of the context of your question. 
Let me anser it one way.  If the code eligible for insertion into CM is from a
designed subsection, even though overall design is incomplete,  the answer is
most definitely yes.  How else will you measure the impact of downstream design
changes on designed and implemented subsections?  
> Yes.
[...Cameron's good stuff...]

George Kambic
standard Merry Christmas disclaimer

Newsgroups: comp.software-eng
From: kevin.jessup <kevin.jessup@mixcom.mixcom.com>
Subject: Re: What is Software Design?
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Distribution: usa
Date: Wed, 23 Dec 1992 17:01:43 GMT

In <7-PCNews-124beta@alpha.saar.de> Georg@alpha.saar.de (Georg Edelmann) writes:

>feathers@serss0 (Michael Feathers @ Florida International University, Miami) once wrote....
>>-The only document developed when software is designed that can be considered
>> this complete is the source code.

>False. At the end of SW design is the Structured Chart (compare it to
               ^^^
>the HW schemes)

You guys do your structure charts AFTER you write your code rather
than BEFORE?  Maybe that's your problem!  ;-)

-- 
Kevin Jessup, kevin.jessup@mixcom.mixcom.com

        "Friends don't let friends run DOS."
                          -- Microware
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: On CM and programmer productivity
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 24 Dec 1992 19:53:13 GMT

In article <Bzrn01.8Bp@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:

>One of the things I've learned over the last few
>years is how important it is for us (us as vendors,
>say) to be prepared to meet customers where they
>are.  One example, which I've lived over and over
>again:  we talk with prospects about leading-edge
>analytic reductions, only-just commercial visuali-
>zation modes, abstract toolsets, and so on, and
>then make a sale because the customer finally be-
>lieves that we'll save him at least some small
>amount of data-management headache.  The same
>companies that talk about AI, OO, NL, ES, ...,
>can be wrenchingly behind on implementing automa-
>tions that were first begun in the '60s.  I like
>Agent models of operation, and your Anticipatory
>Agents in particular, but there are a LOT of organ-
>izations where periodic backups are still a struggle.
>Do you plan to market to them, too--or principally?
>The answer isn't obvious to me.

I would say that the organizations where periodic backups are still a
struggle are, and will remain, the vast majority, i.e. the mass
market. More sophisticated companies CAN write their own sophisticated
custom solutions, or build them from a complex tool kit that
overwhelms the mass consumer.  On the other hand, once there is a tool
for the mass consumer, they often find it fits them well enough too,
and they choose to use it rather than maintain the more complex system
they adopted earlier.  In other words, if you build only for early
adopters, you'll never cross the chasm to the mass market, but if you
target the mass market you may still appeal to early adopters. Lots of
companies that used to have their own custom payroll or personel
system now have off the shelf varieties that appeal to companies that
could never have developed their own.  I do hope that Prescient will
be able to successfully address the mass market in each of its
products. Certainly many people have commented that they can
understand and use Merge Ahead, but are constantly confused by the
other diff and merge tools (cf Sun World May 1992 review by Dave
Taylor).  I hope we can do just as well with other product areas, and
I am to try.



-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.



Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Newsgroups: comp.software-eng
Subject: On CM and programmer productivity
Date: 23 Dec 92 20:19:53 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

I note that in the "When do we inspect" articles that conversation has
migrated to the issue of CM systems and the overhead they introduce.

I'd like to note that in my opinion, this overhead is a result of poor
designs of the existing CM solutions (both tools and processes), at
least from the human factors point of view. (To be fair, with respect to
other issues such as data storage, retrieval, and management many CM
products are truly works of art and represent superior engineering).

Perhaps this is appropriate in a community that values the internals
over the external cognitive and organizational psychology factors, and
which would gladly accept a more limited model  over a better
commercial alternative because the limited model was free.  I know
this is a difficult sell from personal experience--our Merge Ahead
product (new version announced today) beats all others in head to head
tests on both timeliness and accuracy. It is really no surprise--we
are the only developers who spent more time on the cognitive aspects
of the user interface than on the internals.  But the number of people
who are happy driving an engine rather than a car is surprisingly
large. This may be true with regards to CM solutions as well.

Now, after having been involved in designing CM solutions for over 6
years, I'm quite convinced that we can do far better, and I think I know
how to do so. I note several other people have reached the same
conclusion and several of us are working independently to make such a
paradigmatic shift. Application of Prescient Agents (anticipatory systems that
learn your habits without programming) seems quite appropriate to simplifying
this CM area, and could eliminate a great deal of the perceived
overhead. But using such systems will be a fundamental paradigm shift
for users and purchasers.

However, without that shift there will be no way to cross the chasm
from today's CM early adopters to the mass market of people who could
benefit from CM but can't stomach the current systems.

I'm sorry I can't say a lot more about this, as this is a matter of
proprietary  advantage to clients, partners and investors.  Perhaps,
when we have a shrinkwrapped product readers will be able to see if my
predictions are correct in a set of head to head tests.  But I wanted
to challenge other people to question the way CM is done today.
Perhaps once they do so they will contribute to great improvements as well.


-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.
Newsgroups: comp.software-eng
From: surya@eng.umd.edu (Surya Josyula)
Subject: Visual Programming - What is it?
Date: Tue, 22 Dec 92 22:58:05 GMT
Organization: Project GLUE, University of Maryland, College Park

I am looking for information on Visual Programming. I hear the buzz word often and want to get a clearer understanding of the term in relation to software development. Also, I would be interested
in any tools, books or papers for Visual Programming in the UNIX environment. 

 Thanks in advance
  -Surya

Newsgroups: comp.software-eng
From: antonio@tid.es (Antonio Linares)
Subject: Integration testing versus System Testing
Organization: Telefonica I+D
Distribution: comp
Date: Tue, 22 Dec 1992 09:33:47 GMT


  I have some doubts about integration and system testing. I have in
some book notes about integrations test and system test, but:
 
        - What is de exact difference between them?
        - What should test each of them?
        - How do you separate that suite of tests in your organization?
        - When should be done integration test? When system test?
        - Should be integration testing a subset of system testing?
        - How about regresion testing?
        - Who do you think should do each kind of testing? And
          "expert" in the code?
          

  Thanks for your opinion.

--


                         Antonio Linares
			 alinares@tid.es
                         Telefonica I+D
Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Testing bug fixes - request for data
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 3 Jan 1993 02:02:03 GMT


I'd like to start a large-scale, low-key, industry-specific research
project in testing bug fixes.

I have a technique for testing subsystems (small chunks of code up to,
say, 10,000 lines) which is sketchily described in parts of several
papers I'll reference below and completely described in a book I'm
writing.  It's mostly variations on, and additions to, standard
testing techniques.  By applying the technique to real programs
(especially my own), I think I've refined it to a practical balance of
cost and effectiveness.

What I am shakier on is the efficient testing of bug fixes, particularly
in the absence of a good regression test suite.  I'm interested in two
types of testing:

- checking that a change actually fixes the bug.
- checking whether the bug fix induces new bugs because of
  unanticipated dependencies.

(The latter is more interesting, because harder.)

For effective testing, I could test the entire containing subsystem
using the complete technique, but that's not a realistic option: too
expensive.  What I need to do is specialize the technique for
bugfixes, make it good at finding likely problems but not too
expensive to apply to a small change.

I have approaches, but they must be tuned with real data, actual
bugfixes that were incorrect or caused new bugs.  ("Tuning", of
course, includes "throwing out and replacing".)  Since I work for
myself, I don't have access to big bug databases.  So I thought I'd
ask those who do to give me a peek into theirs.  I'll of course sign
non-disclosure agreements.

You benefit by getting my advice on how that bug could have been
found, by eventual publication of articles or a book that will help
your testing, and by getting credit in anything I publish.  The
community wisdom about testing bug fixes will grow faster, to
everyone's benefit.

What do you have to do?  When you fix a bug, and that bug turns out to
have been caused by a previous bug fix, you need to describe the first
(bug-causing) change and what was wrong about it.  I've done this to a
limited extent with one client already.  These types of bugs take time
to explain (diffs often don't suffice), so you must be willing to
spend up to an hour per bug (usually less).  Explaining in person can
be more efficient.  I'll be in the San Jose area a lot in 1993, and I
get out to Boston every once in a while.

If anyone has any helpful literature citations, I'd like those as well.

I expect to spend a few years on this.

Thanks.

Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
Newsgroups: comp.software-eng
From: phardie@nastar.uucp (Pete Hardie)
Subject: Re: Just how sophisticated should we assume progrr & her/his tools to be?
Organization: Digital Transmission Systems, Duluth, GA.
Date: Mon, 21 Dec 1992 17:52:09 GMT

In article <KYV=-5+@engin.umich.edu> jxm@engin.umich.edu (John Murray) writes:
>- The assumption that those who have to maintain one's carefully crafted
>  code will use (or even have access to) the vi editor, or any other 
>  given tool, is flawed. Unfortunately, it smacks of elitism and perhaps
>  a professional desire to keep out the 'ill-informed'. [For precedents,
>  look at the legal and medical professions.] 

But we can (I hope) assume that someone maintaining our code will have access
to an editor of equivalent or greater power, with many of the same features.
I know that both vi and emacs and do token searches ("\<i\>"-like), so why
would anyone later on *not* be using something with an equivalent?


-- 
Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
Position:  Goalie               |
Newsgroups: comp.software-eng
From: kuhn@swe.ncsl.nist.gov (Rick Kuhn)
Newsgroups: comp.software-eng
Subject: Re: Concurrent Engineering
Date: 24 Dec 92 13:59:30 GMT
X-Newsreader: TIN [version 1.1 PL6]

Johan Margono AAS SSD 301-921-3041 (jmargono@opus.starlab.csc.com) wrote:
: Does anyone know what Concurrent Engineering is, who the industry expert
: is, and if there are any papers/articles written on it?
: 
: Thanks in advance.
: 
: -- 
: +-------------------------------+----------------------------------------------+
: | Johan Margono                 | Tel  : (301) 921-3041                        |
: | Computer Sciences Corp.       | Fax  : (301) 840-8934                        |
: | FAA/AAS - Reuse Department    | email: jmargono@starlab.csc.com              |

Another posting mentioned the Concurrent Eng. Research Center at WVU.  You
can get some of their reports by anonymous ftp from:

 babcock.cerc.wvu.wvnet.edu (129.71.14.1).

IEEE Spectrum, July 1991, has a special section on concurrent
engineering.  Next year Academic Press will publish two volumes devoted to
CE in their Control and Dynamic Systems series, for which I contributed an
article on open system software standards and CE.  CE is a popular
buzzword in manufacturing engineering.  The basic idea is to get
marketing, engineering, and manufacturing departments to work together
from the beginning of a product lifecycle, instead of each group working
sequentially and throwing their result over the wall to the next group.
I haven't seen it mentioned much for software products, but some of the 
same concepts appear in various lifecycle models and software process 
methodologies.

--

Rick Kuhn                                   Telephone: +1 301 975 3337       
Natl Institute of Standards & Technology    Fax:       +1 301 590 0932      
Technology Bldg. B266                       Internet: kuhn@nist.gov
Gaithersburg, Md.  20899  USA                       DRKuhn@dockmaster.ncsc.mil
Newsgroups: comp.software-eng
From: kummer@possum.den.mmc.com (Jim Kummer)
Subject: Re: Concurrent Engineering
Keywords: Concurrent Engineering
Organization: Martin Marietta Astronautics Group, Denver
Date: Thu, 24 Dec 1992 04:08:20 GMT

In article <1992Dec21.220005.7937@udel.edu> jmargono@opus.starlab.csc.com (Johan Margono AAS SSD 301-921-3041) writes:
>Does anyone know what Concurrent Engineering is, who the industry expert
>is, and if there are any papers/articles written on it?
>
>Thanks in advance.
>
>-- 
>+-------------------------------+----------------------------------------------+
>| Johan Margono                 | Tel  : (301) 921-3041                        |
>| Computer Sciences Corp.       | Fax  : (301) 840-8934                        |
>| FAA/AAS - Reuse Department    | email: jmargono@starlab.csc.com              |

Concurrent Engineering is normally applied to the front-end engineering
effort for a (mostly) hardware product for which there will be a large-
quantity production run.  It emphasizes getting marketing, engineering 
(all disciplines), packaging, manufacturing all together during the 
conceptualization, design and development, so that Test can actually 
test it, and Manufacturing can actually build it, with little or no
rework, after Engineering has engineered it.  The goal is to avoid
tooling up for a big production run and finding out very late in the
cycle that tolerances are too close, or grommet 'A' can't be installed
without removing the already-installed heat sink, etc.

There is a bulletin board, sponsored by the Concurrent Engineering
Research Center, called CERCnet.  It is accessible via 'telnet' or via
modem over a toll-free number.  I don't have its telnet address handy,
but the toll-free number is 800-331-3808.  There doesn't seem to be a
lot of dialog there, but they do have a large quantity of abstracts of
articles on CE.

Since you are with Computer Sciences Corp., you may be interested in CE
as it applies to software development.  The 'large production run' realm
does not apply to software.  But, one can still insist upon a close
coordination among the marketing folk, the requirements analysts, the
designers, the documenters, the testers, etc., and insist that this
coordination start early enough in the development cycle to circumvent
later rework.

Drop me an email note and let me know whether you found CERCnet to be
useful to your needs.


-- 
 
-- Regards ----- Jim Kummer ----- Martin Marietta Corporation --
----- kummer@pogo.den.mmc.com --- Astronautics Group ----------- 
(standard disclaimer applies) => "I speak for nobody but me"
Newsgroups: comp.software-eng
From: ray@dcs.glasgow.ac.uk (Ray Welland)
Newsgroups: comp.software-eng
Subject: SEE '93  Call for Papers
Keywords: Software Engineering Environments
Date: 22 Dec 92 17:07:45 GMT
Organization: Glasgow University Computing Science Dept.



SEE `93

6th Conference on Software Engineering Environments

Reading, UK, 7-9 July 1993


Call for Papers

SEE `93 will be the 6th in a series of major conferences held on Software
Engineering Environments - the premier professional meeting in a European
location to review, discuss, debate and learn about the most recent
practice and research results in the field, drawn from a world-wide basis.

Work on SEEs demonstrates a maturity in that there is widespread framework
for discussion of problems, exemplified by the ECMA Reference Model,  there
are many Software Engineering tools in use and there are a number of
infrastructures, such as PCTE, available.

However, in spite of substantial investment, the process of building a
Software Engineering Environment is too expensive and the result is often
less than satisfactory.  Is this because of inadequacy of the
infrastructure, such as insufficient support for integration?  Or even that
our technology is just not powerful enough?  Perhaps it is because we do
not have enough experience of trying to build SEEs, even on a bespoke
basis?  Hence the theme of the conference: Construction and Infrastructure.

This notice is an invitation to academic and industrial researchers and
practitioners to submit papers on any aspect of Software Engineering
Environments, though papers which address or emphasise the theme of
construction and infrastructure will be particularly welcome.  Initially,
an extended abstract should be submitted for consideration by the programme
committee.


Instructions for Authors

Submit an extended abstract of 2 -2,500 words to the Conference Chair.
(See 'Advice to Authors of Extended Abstracts", W Pugh, ACM SIGPLAN
Notices, Vol. 26, p353, June 1991)

By: 26 January 1993

Acceptance Notification: 26 February 1993

Full paper by: 18 June 1993, for inclusion in published proceedings.


Tutorials

Proposals for tutorials which address the theme of the conference should be
submitted giving a detailed description of the topic and a table of content
for a 1.0 or 0.5 day tutorial.  Submit to Conference Chair.

By: 26 January 1993


Environments fair

Proposals to demonstrate environments and infrastructures which are
industrial-strength products, prototypes, or research demonstrators are
invited; demonstrations which accompany a paper would be particularly
welcome.  Submit details to Conference Chair.

By: 31 May 1993


Conference Chair;  Mr Ray Welland, Computing Science Department, University
of Glasgow, GLASGOW, G12 8QQ, Tel: +44 41 330 4968; Fax: +44 41 330 4913;
Email: ray@dcs.glasgow.ac.uk.

All submissions should be made in English.
Newsgroups: comp.software-eng,news.answers