*BSD News Article 1810


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!uunet.ca!canrem!telly!robohack!becker!bdb
From: bdb@becker.GTS.ORG (Bruce Becker)
Subject: Re: virtual consoles and screen.
Message-ID: <1992Jul4.192005.16310@becker.GTS.ORG>
Organization: G. T. S., Toronto, Ontario
References: <1992Apr23.073549.6278@sol.UVic.CA> <1992Apr25.072004.5309@compuram.bbt.se> <1992Apr26.135623.2170@pegasus.com>
Date: Sat, 4 Jul 1992 19:20:05 GMT
Lines: 363

In article <1992Apr26.135623.2170@pegasus.com> richard@pegasus.com (Richard Foulk) writes:
|>: I would counsel against adding Virtual consoles directly to the
|>: kernel.  Instead, the GNU Screen package should just be ported.
|>
|>Does screen give all features that kernel virtual consoles give?
|>- All screens work concurrently and independently.
|
|Yes.
|
|>- The screens can have different video modes.
|
|No.  But could be added.
|
|>- You can ran graphics (like X) on one screen, and text on others.
|>  (this also include scancode mode on one of the multi-screens)
|
|No.  Screen is more general purpose than that.  Screen will even work
|under X.
|
|>- No overhead with ptys etc.
|
|Screen does use ptys.  But vt's have overhead of their own.
|
|Screen is much more general, has lots of useful features that vt's
|don't.  And it isn't tied to the console.  Screen over a high-speed
|modem link is great stuff.
|
|And it's not another wart on the kernel.


	How about a comparison between "screens"
	and "MGR" for this purpose...



Newsgroups: talk.politics.misc
Subject: Re: How to Fight Police Brutality and the Sytem Which Breeds It
Summary: 
Expires: 
References: <1992May7.032124.12776@watdragon.waterloo.edu> <1992May7.135137.1185@watdragon.waterloo.edu>
Sender: 
Followup-To: 
Distribution: 
Organization: G. T. S., Toronto, Ontario
Keywords: oppression, police-brutality, slavery, exploitation, abortion

In article <1992May7.135137.1185@watdragon.waterloo.edu> vehaag@crocus.waterloo.edu (Viktor Haag) writes:
>In article <1992May7.032124.12776@watdragon.waterloo.edu> bghauk@watdragon.waterloo.edu (Brian G. Hauk) writes:
>>
>>May 6, 1992             A System of Injustice           PLEASE DISTRIBUTE
>>
>>Demonstrations in San Francisco, Los Angeles, Atlanta, Las Vegas, New York,
>>Seattle, Toronto and other cities sparked by the acquittal of four cops who
>>brutally beat Rodney King and the killing of another Black man by cops in
>>Toronto are a sign of rising class tensions. These tensions are between
>>and within social classes and grow out of the cumulative effects of the
>>economic crisis of world capitalism.
>
>[ acres of text removed here ]
>
>>What's needed is an international working class perspective on fighting the
>>capitalist system of exploitation and oppression; a plan to build working
>>class solidarity and leadership among all people fighting for justice.
>>
>>For coverage of the fightback against the capitalist's offensive, read the
>>MILIANT newspaper, a weekly published in the interests of working people
>>by those involved in fighting for justice. Call (212) 243-6392 for
>>information or the PATHFINDER BOOKSTORE nearest you.
>
>I am not entirely certain that uw.general is the forum for such slanted
>political tirades.
>
>Please keep this is talk.politics.misc, and the other, more appropriate 
>newsgroups, and out of uw.general. 
>
>
>
>-- 
>Viktor Haag 
>		            |  "We are not thugs.  We are not fanatics.
>vehaag@crocus.uwaterloo.ca  |   We are vitamin supplements to justice."   
>			    |				: a Selector


Newsgroups: news.sysadmin
Subject: Re: Please estimate cost of small news system.
Summary: 
Expires: 
References: <1447@heurikon.heurikon.com> <BRTMAC.92May9174517@maverick.ksu.ksu.edu>
Sender: 
Followup-To: 
Distribution: 
Organization: G. T. S., Toronto, Ontario
Keywords: 

In article <BRTMAC.92May9174517@maverick.ksu.ksu.edu> brtmac@maverick.ksu.ksu.edu (Brett McCoy) writes:
>In article <1447@heurikon.heurikon.com> lampman@moose.heurikon.com (Ray Lampman) writes:
>
>>I need a "ball-park" dollar estimate for a  small  public  access
>>Unix system with news and mail facilities, requirements follow:
>>
>>$<     > Initial cost of system hardware.
>>	    Processes 1 day's full news feed within 2 hours.
>
>This is not going to be a small system.  A *full* news feed consists of
>15000+ articles a day.  That means it has to process a little over 2
>articles per second.  I doubt that is going to be possible on any machine
>under $10,000.
>
>>	    Comfortably supports 8 modem (at 9600 bps or faster)
>>	    - users (running news and mail tools) simultaneously.
>
>A SPARC IPC or equivilent can probably do that okay.  An 8 port serial
>expansion box for the SCSI buss costs under $1000 I believe.
>
>>	    Hardware allows for future network connection.
>
>Any modern UNIX box should do that.  Even most PC's running UNIX allow
>for that.
>
>>	    Memory holds most processes with minimal swapping.
>
>I'd say 32M would be a minimum, although you might get by with 16M or
>24M if you hold off processing news until no one is logged on.
>
>>	    Disks can store 1 month's full news feed.
>
>At 15000 articles a day with an average article size of 2k you would be
>looking at 15000 * 31 * 2048 = 952320000 bytes or 952Mbytes.  A 1.2G
>drive should do it, but that doesn't leave much room for expansion so
>I'd go for a 2G drive or 2 1.2G drives.  The problem with 2 drives is
>that most of the software doesn't understand a split news spool very
>well.
>
>>	    Includes a minimum of 8 serial ports.
>
>Going to be an expansion card or SCSI bus peripheral on most systems.
>Figure $750+.
>
>>$<     > Initial cost of establishing communication facilities.
>>$<     > Monthly cost of maintaining communication facilities.
>>	    8 telephone modems (9600 bps or faster).
>>	    8 telephone lines, accessed via one telephone number.
>>
>>$<     > Initial cost of establishing a full news feed.
>
>Find a friendly site near you to feed you.  Most sites will do it
>for free if you ask real nice.
>
>>$<     > Monthly cost of maintaining a full news feed.
>>	    Full news feed comes from uunet (at 9600 bps or faster).
>>	    Runs latest C-news software including all patches.
>>	    Mail is exchanged with uunet (at 9600 bps or faster).
>
>Once again, find someone near you that is connected and it might not
>cost you a thing.
>
>>Eventually,  I'll  need  pointers  to  appropriate  hardware  and
>>software. But for now, I'm just trying to get a feel for how much
>>a system like this might cost to buy and operate. So, what's  the
>>approximate  price  of the cheapest system that fits the bill? Is
>>it in the $20K "ball-park", or $10K or less? What if  the  system
>>were  half as fast? Had half as much disk space? Fewer modems? It
>>would be great to hear from someone who currently  works  with  a
>>system  like  this.  Please  send  mail.  If  there's  sufficient
>>interest, I'll summarize and post. Thanks much,
>
>I'd say $20K to get it completely set up once you buy the CPU, drives,
>modems, install the phone lines, and get a network connection.  Could
>be more depending on where you are.
>
>++Brett;


Newsgroups: alt.conspiracy.jfk
Subject: Re: Opening the Archives
Summary: 
Expires: 
References: <1992Apr29.200501.11763@husc3.harvard.edu> <1992May6.202758.25241@samba.oit.unc.edu> <1992May12.033559.7445@usenet.ins.cwru.edu>
Sender: 
Followup-To: 
Distribution: 
Organization: G. T. S., Toronto, Ontario
Keywords: 

In article <1992May12.033559.7445@usenet.ins.cwru.edu> dxc4@po.CWRU.Edu (David Condon) writes:
|
|In a previous article, bdb@becker.GTS.ORG (Bruce Becker) says:
|
|>In article <1992May6.202758.25241@samba.oit.unc.edu> Robert.Daniels@bbs.oit.unc.edu (Robert Daniels) writes:
|>|I have read that Nixon initially claimed not to remember where he was
|>|when he heard JKF had been shot, and then later said he was in a taxi in
|>|Manhattan, going from the airport [he had just flown in from Dallas] to
|>|his apartment.
|>|
|>|But I had not previously heard about Bush's whereabouts on 11/22/63. 
|>|Could you supply the source?
|>
|>
|>	Carberry has identified him as one of the
|>	airline "staff" who handled the body bag,
|>	and alludes to a photograph
|
|Who's Carberry??? Another country heard from.


	Andrew S. Carberry, "Origins of the P2 Lodge",
	Halcyon Press, 1967.


Newsgroups: news.software.b
Subject: Re: rnews -U hangs & locks 'sys' file
References: <ey0kkB4w164w@qed.cts.com> <8144@boink.UUCP>
Organization: G. T. S., Toronto, Ontario

In article <8144@boink.UUCP> root@boink.UUCP (Super User) writes:
|In article <ey0kkB4w164w@qed.cts.com>, tim@qed.cts.com (Tim Capps) writes:
|> HELP!
|> 
|> I am having the strangest problem which is driving me nuts!
|> 
|> I am running B-news on a Xenix 2.3.3 system (386/SX).  I am running
|> ihave/sendme with 3 other sites, and feeding small amounts to a couple more
|> using a straight feed.
|> 
|> Almost every morning, PS shows that there are a ton of jobs unpacking
|> news and all that, but they aren't running.  One of them is always RNEWS -U
|> If I look in /usr/spool/news/.rnews, there are some files in there, but
|> they typically aren't very large or unusual in any way.  Apparently,
|> rnews -U is locking the /usr/lib/news/sys file, which causes all other
|> news handling tasks to be suspended until it gets unlocked.  This really
|> smells like a deadly embrace situation to me, but I have no idea what
|> the real problem could be.
|> 
|[ stuff deleted ]
|
|	I am running Bnews on Xenix 2.3.2 (286). Same problem. I've seen this 
|problem posted here before, but with no response. The thing I can't figure
|out is the problem seems intermittent, that is, it is not consistent. Sometimes
|it will, sometimes it won't. The problem happens after running expire, and
|rnews will unpack stuff that might have come in during expire. If you check 
|your logs, you will find that rnews is waiting forever on a lock. What drove
|me nuts is this does not always happen, just enough for me to give up on 
|expire and resort to other means. Basically, I nuke articles in a script,
|and rebuild the database now and then. A pain, but it works.
|
|    The inconsistency makes me believe it might be a kernel bug. The bnews
|code as far as I can tell looks correct. It works sometimes. I have only
|seen people with SCO Xenix systems complain about this problem. That is 
|what makes me really supsect the problems lies in SCO Xenix.
|
|    I'm cross posting this reply to comp.unix.xenix.sco, maybe somebody there
|might be able to shed some light. If they are using vnews though, they won't
|see this article!
|
|    If anybody wants to jump in here, I'm all ears.


	This is not likely a kernel bug (altho there
	are lots in Xenix 8^) - it happens in other
	systems too.


	The ihave/sendme locking code produces a deadlock
	situation when invoked as part of the rnews -U
	processing.


	Three remedies suggest themselves -

		1. turn off uuxqt processing during expire

		2. use lock files instead of the kernel
		   locking primitives

		3. upgrade to C news


	I had done 1. before, then 3.
	Installing C news was certainly the proper solution...


Newsgroups: news.software.b
Subject: Re: compiling new cnews on ISC 2.2.1
References: <Bo7HDM.D5u@zoo.toronto.edu> <1992May17.035903.4133@robohack.UUCP> <BoEzDu.HK@zoo.toronto.edu>
Organization: G. T. S., Toronto, Ontario

In article <BoEzDu.HK@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
|In article <1992May17.035903.4133@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
|>Second, note that all machines running an O/S based on AT&T UNIX
|>System V Release 3.x have a statfs(2) call, [Release 4.0 has
|>statvfs(2) instead, but still include ustat(2)].  Ustat(2) has been
|>deprecated for nearly a decade!
|
|Ustat() may be deprecated, but it is still *far* more widespread than
|statfs() in the System V community.  Moreover, I really lack the energy
|to try to keep up with every incompatible variant AT&T spews out.
|(System V:  consider it out of control.)  Ustat() may be an antique, but
|it's been in the SVID forever, and so lots of people support it.  I'll
|probably do something about statvfs(), in hopes that it will be stable
|over at least the next one or two System Vs.  I'm *not* going to support
|yet another statfs() variant; two is too many already.


	The problem with ustat() (and stat() for that
	matter), at least in SysVr4, is that they expect
	all file systems to have inode counts which fit
	into 16 bits.


	If the ufs file system is created on a large partition
	it certainly will have more than 65535 inodes, which
	will cause interesting problems when expressed as a
	16-bit quantity.


Newsgroups: rec.backcountry,alt.tasteless
Subject: Re: Social Disease (was Water Filters)
References: <wcwk+tj@lynx.unm.edu> <11091@inews.intel.com> <sandrock.706483759@aries>
Organization: G. T. S., Toronto, Ontario

In article <sandrock.706483759@aries> sandrock@aries.scs.uiuc.edu (Mark Sandrock) writes:
|pharvey@mipos3.intel.com (Paul Harvey) writes:
|
|>Yeah, it's a horrible, germ-filled world out there, ...
|> [Copious colorful precautions deleted.]
|
|Well, I wouldn't go *that* far, but I hate people who don't wash their hands
|when using public restrooms. Cats are more hygienic, in my opinion ;-)


	I am very sanitary, I lick my hands afterwards


Newsgroups: comp.sys.3b1
Subject: Re: 3.5" FD advice needed
References: <1992Jun28.014040.3323@alw.nih.gov> <1992Jun29.233341.25965@ceilidh.beartrack.com>
Organization: G. T. S., Toronto, Ontario

In article <1992Jun29.233341.25965@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
|In article <1992Jun28.014040.3323@alw.nih.gov> crtb@helix.nih.gov (Chuck Bacon) writes:
|>Following some thread from a year or two back, I tried replacing my
|>5.25" FD drive with a 3.5" drive.  I hoped to get 1.4 MB that way.
|
|	You'll need to do more than replace the drive and the iv table to
|get a 1.44 MB drive to work on the 3B1.  The 1.44 uses a different data rate
|than the standard 3.5" drive.  You'll have to find someplace to extract a
|new clock for the floppy controller chip.


	Commodore has recently started shipping Amiga 3000's
	with a 1.44 MB drive - their systems have the same
	data rate problem, so they's arranged for the drives
	to run at 1/2 speed in 1.44 MB mode.  This produces
	the proper data rate (but there are twice as many
	sectors/track, natch).


-- 
  ,u,	 Bruce Becker			Toronto, Ontario
a /i/	 Internet: bdb@becker.gts.org	Uucp: ...!web!becker!bdb
 `\o\-e	 \*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/
 _< /_	 "Awaken the Geek Within" - Anthony Robot