HDTenEightyP/NetNews huggingface dataset:
From: rsk@gynko.circ.upenn.edu (Rich Kulawiec)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 02:07:48 GMT
Organization: GSP Whitewater Slalom Racing Team

In article <BxM9JI.4yw@mtholyoke.edu> jbotz@mtholyoke.edu (Jurgen Botz) writes:
>I agree.  Heh... Not only are those who keep pronouncing the death of
>Unix dead wrong, but their credibility is starting to rot.

In that same vein, from time to time, I recall with great satisfaction
a conversation I had with one of the bigwigs at Forth, Inc. back in 1982.
This person explained to me in glorious detail why Unix was just a passing
thing, and how in a couple of years we'd all be writing Forth and running
their monitor-like OS, and ...

I think of this everytime I read another vaporware announcement
concerning Windows NT.  Unix outlasted CP/M and VMS and RSTS and
AOS and <add your favorite long-obsolete operating system here>; I suspect
that it will outlast Windows NT as well.  (Although Plan 9 could
give it a serious run for the money in a few years.)

---Rsk
Newsgroups: comp.unix.wizards
From: orjanr@staff.cs.uit.no (rjan Robertsen)
Subject: Broadcast detection from the socket layer ?
Keywords: socket, broadcast
Organization: University of Troms
Date: Mon, 9 Nov 1992 09:43:36 GMT

Hello, wizards

I have the following (hopfully not too simple) question(s) for you:

	Given access to the socket structure and accompanying information,
	is it possible to determine if a received packet (message) originally
	was sent as a broadcast message ? That is, where/when is the original 
	to adress droped ?

	If it's not possible from the socket layer, how far "down" do I
	have to look to find this information, and will it be possible to
	forward this info to the socket layer in any way ?

Thanks in advance.
Have a nice day.
-- 
////      rjan W. Robertsen            |e-mail   : orjanr@staff.cs.uit.no////
///Dept. of Computer Science, University|Home     : +47-83-82897          ///
// of Tromsoe, N-9000 TROMS, NORWAY    |Phone/Fax: +47-83-44053/44580    //
Newsgroups: comp.unix.wizards
From: so@brownie.cs.wisc.edu (Bryan S. So)
Subject: Re: The Problem with UNIX
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.
Date: Wed, 11 Nov 1992 21:07:29 GMT

Concerning Don Norman's paper "The Trouble With UNIX", Datamation 27,
rsk@gynko.circ.upenn.edu (Rich Kulawiec) writes:
 
>Norman's paper is (a) a decade out-of-date and (b) extraordinarily
>inaccurate, as it was when published.  In my opinion, it represents
>the uninformed rantings of someone who is simply too lazy to read the
>manuals and therefore should not be using a computer at all.

I agree it's a decade old but can you indicate why it's inaccurate?

To me, some problems like "cat a b > b" are obviously undesirable
designs and still unsolved after more than a decade.  


Bryan
Newsgroups: comp.unix.wizards
From: wmchung@eng.ie.cuhk.hk (chung wai man)
Subject: About signal loss problem
 
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Tue, 10 Nov 1992 08:28:59 GMT

Newsgroups: comp.unix.wizards
From: joel@wmi.com (Joel Coltoff)
Subject: Identifying SBus adapter cards
Organization: Woodward McCoach, Inc.
Date: Wed, 4 Nov 1992 19:59:29 GMT

The hardware platform is Sparcstations

I've got a problem I know is solvable but have reached the limit of
my resources in dealing with it. Basically I need to duplicate some
of the functionality of the 'devinfo' program. I can't figure out
what the correct ioctl() incantation to do on /dev/openprom is.

The purpose of all this is that the product we support requires the
customer to set jumper options on an external box. To verify this
they run a program and watch for a particular pattern of lights
to appear. This is the simple part. The bad thing I am doing is
counting on the customer to invoke the program correctly. i.e.
If the SBus card is slot 1 they type 'cfgtest 1'. If it's in
slot 2 they type 'cfgtest 2'. If it's really in slot 1 and they
type 'cfgtest 2' then whatever is in slot 2 gets some (probably)
meaningless bit pattern written to it.

How can I verify from a non-kernel program that the SBus card I'm
about to write to is the correct one?

Please send email as I do not get this newsgroup here.

	Thanks,
	  - Joel
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: pack@acd.acd.ucar.edu (Daniel Packman)
Subject: Verbose errors on demand - was Re: The Problem with UNIX
Summary: environment variable could control it
Organization: Ntl Center for Atmospheric Research, Atmospheric Chemistry
Date: Thu, 12 Nov 1992 23:26:49 GMT

In article <1992Nov12.204710.5808@reed.edu> kanderso@reed.edu (Karl Anderson) writes:
>
>Is there any reason why there can't be another stream for more
>user-friendly messages?  We have stdin and stderr, why can't there be
>a standard verbose stream as well?  Experienced users could just
>direct it to /dev/null , or, to save cpu time, could have a flag that
>would disable it altogether.
>
I see no reason for the complexity of another stream... just have an
environment variable "VERBOSE" which, when defined, would give reams
of nasty commentary, ring terminal bells, and blow terminal whistles.

--
Dan Packman     NCAR                             INTERNET: pack@ncar.UCAR.EDU
(303) 497-1427  P.O. Box 3000
                Boulder, CO  80307-3000        NSI/DECNET: 9583::PACK
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: The Problem with UNIX
Organization: The University of Texas System - CHPC
Date: Fri, 13 Nov 92 22:47:18 GMT

In article <BARNETT.92Nov13093417@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
>In article <1992Nov12.193707.27532@chpc.utexas.edu> michael@chpc.utexas.edu (Michael Lemke) writes:
>>   Well, fixing typos is neat but it is not the essential problem.  My
>>   main complaint about Unix on the user interface level is that there is
>>   no command line interpreter.  What I mean is that after the shell munged
>>   your command line it is *completely* up to the program to interpret the
>>   command line and there is no system function available to parse even
>>   these `standard' options. 
>
>Some look at this as an advantage. You are probably complaining about
>the inability to perform
>	rename *.old *.new
>

No, I don't.  I am complaining that the options are a) parsed
inconsistently (`bla -lx a' might be valid and `bla -l x a' not but
`foo -l x a ' is ok and `foo -lx a' is not) and b) that -l means long
for ls -l but library for f77 -l.  I want ls -long and f77 -library and
be able to abbreviate both -long and -library because `long' and
`library' is what I mean and not -l.

I am not addressing the question of parameter substitution and I/O 
redirection at all as you do in the rest of your post.  That would open 
a whole new can of worms.

[worms eaten by the fish]

>
>
>It sounds like most of your problem is due to the large number of UNIX
>utilities. How many does DOS have? 

No idea.  I don't know DOS.

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.unix.wizards
From: arne@nats.informatik.uni-hamburg.de (Arne Ludwig)
Subject: Re: Process 'purge' revisited.. Unix missing this?
Organization: University of Hamburg, FRG
Date: 10 Nov 92 17:00:08 GMT

tpaquette@ita.lgc.com (Trevor Paquette) writes:
>It is impossible to 'purge' a process witing on a hung device.

An unkillable process waiting on a hung device is just a sign of a broken
device driver.

> Is this a deficency in Unix? Should it be added? Will I ever win the
>lottery?

No. No. Perhaps.
--
Arne Ludwig
ludwiga@informatik.uni-hamburg.de			arne@rrzbu.hanse.de
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: SUN NFS sync
Keywords: sync
Date: 5 Nov 92 23:21:17 GMT
Organization: Auspex Systems, Santa Clara

>The clue was the table posted showing pagesize I/O, that the little bell
>rang and said your living in SunOS 3.x oops.

Umm, I don't think it was even the case in 3.x - or 2.x, for that matter
- that NFS writes were synchronous on the client side.  The 4.x VM
system is irrelevant to the discussion; 3.x and earlier releases used
the traditional UNIX buffer cache scheme for I/O, both on local file
systems and over NFS.
From: bush@ecs.ox.ac.uk (Mark Bush)
Newsgroups: comp.unix.wizards
Subject: Re: Any TeX (compilation) Gurus out there?
Keywords: TeX, make
Date: 12 Nov 92 15:38:16 GMT
Organization: Oxford University Computing Laboratory
Originator: bush@thom5.ecs.ox.ac.uk

In article <BxKJK0.8Mr@mentor.cc.purdue.edu> parson@pop.stat.purdue.edu (Eric Parson) writes:
#get MF to process the plain.mf file, but in the 'Makefile' command file,
#it displays the line:
#	inimf plain; input modes; dump
#Well, it gets through the inimf, but fails the input.  Now there aren't that
#many copies of files with the name 'modes' in them (two to be precise, and 
#one is amsmodes.mf), thus I thought that moving a copy of modes.mf from the
#input directory would solve my problem.  It didn't.  Now I don't know what 
#else to do.  

In what manner didn't it?

From README.WEB2C:

------------------------------------
10. `make bases' to make the base files for Metafont that you want.
    Besides the variable `bases' in ./Makefile, you may also want to
    change the variable `localmodes'.  It is also a good idea to try to
------------------------------------

and from ./Makefile:

------------------------------------
# The name of the file that defines your local devices, for use with
# Metafont.  (Only relevant during `make bases'.)  I urge you to get the
# file `modes.mf', which defines all known modes, plus useful
# definitions for all fonts.  It's available from ftp.cs.umb.edu
# [192.12.26.23] as pub/tex/modes.mf, among other places.
localmodes=modes
------------------------------------

You should place a copy of this into the area you have defined in lib/site.h
as the value of MFINPUTS.

Mark
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: ckd@eff.org (Christopher Davis)
Subject: Re: The Problem with UNIX
Followup-To: comp.unix.shell
Organization: Electronic Frontier Foundation Tech Central
Date: Wed, 11 Nov 1992 23:50:14 GMT

[cleaning up followups]
Mike> == Mike Hollander <mike@nttor.uucp> 

 Mike> Things that bother me about the command line (I'm using Motorola
 Mike> UNIX System V/68 Release 3.71 running a Korn shell using vi-type
 Mike> command line editing on a VT420), in no particular order:

 Mike> 1) It is possible to backspace over the prompt.

Get BSD tty drivers or tcsh.

 Mike> 2) Running over past the end of the line onto the next line does not 
 Mike>    allow you to backspace back to the previous line, and if you     
 Mike>    backspace at the last column of a line it is possible to miss
 Mike>    a character and therefore not backspace over what you think
 Mike>    you are backspacing over.

This might be a termcap issue.  Try tcsh.

 Mike> 3) It doesn't seem possible to map the arrow keys on the keyboard
 Mike>    to enable you to press up arrow to get the previous command, or
 Mike>    to use left arrow to move backwards through the line.

tcsh.

 Mike> 4) It doesn't seem possible to store macros that could be run with
 Mike>    a single keypress.

tcsh.

 Mike> 5) The function keys don't do anything and cannot be made to do
 Mike>    anything on the command line.

tcsh.

 Mike> 6) The insert and remove keys cannot be made to place you in insert
 Mike>    mode or remove characters.

probably tcsh.  (I don't know, I don't do modes.)

 Mike> That's a short list off the top off my head. If anyone has methods
 Mike> to fix these complaints please feel free to respond!

Get tcsh. ;)

zsh and bash probably fix most or all of these complaints also.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>
From: acourtny@unix1.tcd.ie (Antony A. Courtney)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 22:36:08 GMT
Organization: Trinity College, Dublin

In <1452@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
>In an article, boyd@prl.dec.com (Boyd Roberts) writes:
>>The real problem, as Rob has so eloquently put it:
>>
>>    ``Not only is UNIX dead, it's starting to smell really bad.''
>
>I find it amazing that people, apparently in pursuit of some small amount of
>enjoyment, spend their time proclaiming the death of UNIX.
> [...]	
>I have heard UNIX to be proclaimed dead and buried for years now.
> [...]
>So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
>paying my last respects ...

UNIX once referred to a research operating system which was very cleanly
designed on a coherent set of principles, and whose structure was well within
the intellectual grasp of a single human being.

There exists a certain class of modern operating systems, all of which are
referred to by the name UNIX.  These operating systems have their origins in
the system I refer to above, but have "enhanced" the original system with lots
of new "features" which you and I find useful (terminal handling, job control,
networking, etc.).  But in the process of adding all of these new "features" to
UNIX, these new operating systems somehow lost the brevity, clarity, simplicity
and structural elegance of that other system once called UNIX.

UNIX is dead.  Long live UNIX.

[all of the above are obviously purely my own opinions...]

	-antony

>-- 
>Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (714) 681-2623
>Pacific Software Group, Riverside, CA
--
********************************************************************************
* Antony A. Courtney                              Email: acourtny@unix1.tcd.ie *
* Computer Science Department                            antony@george.lbl.gov *
* Trinity College, Dublin, Ireland                Phone: 01+353+1-607389       *
Newsgroups: comp.unix.wizards
From: eriseman@dw3f.ess.harris.com (Eric Riseman)
Subject: Makefile Parameter Passing
Date: Fri, 6 Nov 1992 16:38:56 GMT
Reply-To: eriseman@dw3f.ess.harris.com (Eric Riseman)
Organization: Harris GISD

This may or may not belong here, but I figured that you "wizzards" out
there could
help me the fastest.
How does one pass a file name into a Makefile as a parameter and how is
this file
name used within the Makefile? 

Here is the "guts" of my Makefile :
(kind of hard coded for file name...e1.c)

      SYSCC = -D_NO_PROTO -U_POSIX_SOURCE
       LIBS  =  -lXm -lXt -lX11
       INCPATH = -I/usr/include/X11
       e1 :  e1.c
  
             cc $(SYSCC) $(INCPATH) e1.c $(LIBS) -o e1

The OBJECTIVE : to have a Makefile that is generic.
 ie : can be used by files..... e1.c  e2.c  e3.c  etc.
       make e1        make e2        make e3        etc.


Thanks in advance for this trivial pursuit
ESR
From: sinan@bcsaic.boeing.com (Sinan Karasu)
Newsgroups: comp.unix.wizards
Subject: Solaris 2.0/2.1 Realtime programming
Date: 11 Nov 92 20:35:32 GMT
Distribution: comp.unix.wizards
Organization: Boeing Computer Services AI Center, Seattle

Hi wizards,
I am porting an application that requires very fine
timing control to Solaris 2.0/2.1. I need to be able to schedule
my program at given time increments. The time increment can be
anywhere from 1 millisecond to 50 milliseconds. I gave played
with setitimer and SIGALRM , they do work fine except I can not
get better than 10 millisecond granularity. So I decided
to try something more hardware oriented and noticed that there are
2 timer/counters in the MMU chip.
Questions:

1) Does the OS use either or both of these counters?
2) Are there other timers available on the Sparc platform?
3) Does the equation change if I use a VME based SparcEngine?
4) Does/Has anybody done/? any work in this area and give me some
   pointers?
5) Are there other calls in Solaris 2.0 and derivatives that would
   allow me to what I am trying to do ????



Thanx for any and all answers/pointers/criticism/etc...
Sinan Karasu
From: arnej@kari.fm.unit.no (Arne Henrik Juul)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 07:36:32 GMT
	<1992Nov11.210729.11676@cs.wisc.edu>
Organization: University of Trondheim

In article <1992Nov11.210729.11676@cs.wisc.edu>
 so@brownie.cs.wisc.edu (Bryan S. So) writes:

   To me, some problems like "cat a b > b" are obviously undesirable
   designs and still unsolved after more than a decade.  

Well, you can make this error in other operating systems too, here's VMS:
$ define SYS$OUTPUT myfile
$ type myfile,anotherfile

Of course, VMS keeps every version of every file I have ever made
(assuming I'm a naive user who haven't heard of purge), but then
I probably won't know how to get the old version back, either.

Probably ANY decent OS/UI will make it possible to make exactly this
mistake. To put it another way: If you add features to make it
impossible to make this kind of mistake, it won't be a good OS/UI
anymore.

It's just that it is much easier to do it in Unix. Remember: Unix
was designed to make it possible to do smart things easily, it was
NOT designed to make it hard to do dumb things.

I can imagine it will be impossible to make this mistake in
Windows/NT, but I fully expect that it will be impossible to
concatenate two files in Windows/NT too.

-- Arne H. Juul, arnej@lise.unit.no
Xref: sparky comp.unix.wizards:4605 comp.unix.shell:4639 comp.unix.misc:4098
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 17:17:19 GMT
Followup-To: comp.unix.wizards
Organization: Pacific Software Group, Riverside, CA

In an article, boyd@prl.dec.com (Boyd Roberts) writes:
>The real problem, as Rob has so eloquently put it:
>
>    ``Not only is UNIX dead, it's starting to smell really bad.''

I find it amazing that people, apparently in pursuit of some small amount of
enjoyment, spend their time proclaiming the death of UNIX. This sort of thing
is really beginning to take on the flavor of the apocalyptic doomsayers (you
know the type ... they run about the streets wearing dirty plaid suits bellowing
"Repent Now, For the End is Near!").

I have heard UNIX to be proclaimed dead and buried for years now. I have no
doubt that there are those who would *like* UNIX to be dead, but desire alone
does not make a thing so. Microsoft is a good case in point, I suppose.

So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
paying my last respects ...

Oh, and by the way, I do assume then that you are using VMS, DOS, or perhaps a
beta version of Windows NT?  You wouldn't be caught *dead* using UNIX, am I
right? :-)

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (714) 681-2623
Pacific Software Group, Riverside, CA
Newsgroups: comp.unix.wizards
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Oct 29 00:48)
Followup-To: poster
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Sun, 8 Nov 1992 11:00:46 GMT
Expires: Tue, 8 Dec 1992 11:00:27 GMT

Please take a moment to read this before posting to comp.unix.wizards
for the first time.

comp.unix.wizards is for in-depth discussion of advanced unix topics.

Elementary questions do not belong in comp.unix.wizards.  Although some
socket questions (for example) are appropriate, "How do I program with
sockets?" is not.

Crossposting to comp.unix.wizards and comp.unix.questions is
inappropriate.  Plenty of wizards read comp.unix.questions and answer
questions there.

A wizard is someone who can rewrite the entire system from scratch.  If
you are not a wizard, you are welcome to follow along the discussions
anyway.  You'll learn quite a bit about how UNIX works.  Caution: post
to wizards only if you are yourself a wizard.

For a list of answers to frequently asked questions (FAQ), please refer
to comp.unix.questions (or comp.lang.c, news.answers, etc...).  "How do
I delete a file whose name starts with a '-' ?" is an example of such a
question.  Please do not ask or answer FAQ's on the net.

Write to Unix-Wizards-Request@BRL.MIL (Subject: subscribe.  Any
message.) if you want a daily digest of this newsgroup mailed to you.

To unsubscribe from the unix-wizards mailing list, send mail to
"info-unix-cancel@brl.mil", no text required.  It is incorrect to post
such requests to the list, or to mail them to me, though others may
mistakenly do so.

E-mail comments about this posting are welcome.  From time to time I'll
summarize them.

Brian
--
These opinions are mine, and do not necessarily reflect those of any
academic department or computing service at Rensselaer.
Newsgroups: comp.unix.wizards
From: misar@rbg.informatik.th-darmstadt.de (walter misar)
Subject: Re: Keyboard hit in C programs
Date: Tue, 10 Nov 1992 14:54:17 GMT
Organization: TU Darmstadt
Keywords: Keyboard hit, C programs, UNIX

In article <1dms9iINNa6m@agate.berkeley.edu>, bernt@valois (Bernt Skottun) writes:
> 
> I am in the process of adapting a C program from the PC for
> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
> In this program it is essential that
> the user be able to stop certain parts of the program
> (e.g. an inner loop) by hitting the keyboard (any key
> is fine) while as long as the keyboard is not touched the execution
> of the program will continue un-interupted (thus a procedure
> which requires, or expects, the user to type in a key stroke at certain
> intervals will not do). In the DOS environment
> I have been able to do this with the "kbhit()" function.
> My question is: what is the equivalent function in the UNIX
> environment? or how does one go about creating such a function?
> Any suggestions will be very welcome. Thanks a lot.
> Bernt Skottun, bernt@valois.berkeley.edu 
>

Ok, since ^C is an 'any key' you only have to catch the SIGINT you
get if ^C is hit.  

#include <signal.h>
signal(SIGINT,function)

In function() ( prototyped as void function(void) ) the first call should
be signal(SIGINT,function) because the behavior of SIGINT is reset to default
by the signal-handler.

Walter
Newsgroups: comp.unix.wizards
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: The Problem with UNIX
Organization: Mount Holyoke College
Date: Thu, 12 Nov 1992 18:47:42 GMT

In article <1452@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
>In an article, boyd@prl.dec.com (Boyd Roberts) writes:
>>The real problem, as Rob has so eloquently put it:
>>
>>    ``Not only is UNIX dead, it's starting to smell really bad.''
>
>I find it amazing that people, apparently in pursuit of some small amount of
>enjoyment, spend their time proclaiming the death of UNIX. This sort of thing
>is really beginning to take on the flavor of the apocalyptic doomsayers (you
>know the type ... [...]

I agree.  Heh... Not only are those who keep pronouncing the death of
Unix dead wrong, but their credibility is starting to rot.
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
Newsgroups: comp.unix.wizards
From: tpaquette@ita.lgc.com (Trevor Paquette)
Subject: Process 'purge' revisited.. Unix missing this?
Organization: Landmark/ITA Inverse Theory and Applications
Date: Fri, 6 Nov 1992 19:27:58 GMT


 All the responses I have recieved have all said exactly what I thought.
It is impossible to 'purge' a process witing on a hung device.

 Is this a deficency in Unix? Should it be added? Will I ever win the
lottery?

  Trev
--
Name : Trevor Paquette       | Landmark/ITA             |  _\___ Fahrvergnugen
Email: tpaquette@ita.lgc.com | Calgary, Alberta, Canada | /     \____
Visitor from CyberSpace      | (403) 269-4669           |/ G60       \
Renegade of Virtual Reality  | #include <disclaimer.h>  |\-O------O--/