HDTenEightyP/NetNews huggingface dataset:
From: jliddle@rs6000.cmp.ilstu.edu (Jean Liddle)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: Sun, 27 Dec 1992 22:31:46 GMT
Organization: Illinois State University
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages

In article <2564@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>
>Do you know that Japan vote AGAINST ISO10646/Unicode, because it's not
>good for Japanese?
>
>>So even if the Unicode standard ignores backward compatability
>>with Japanese standards (and specific American and European standards),
>>it better supports true internationalization.
>
>The reason of disapproval is not backward compatibility.
>
>The reason is that, with Unicode, we can't achieve internationalization.
>
>Unicode can not cover both Japanese and Chinese at the same time, because
>the same code points are shared between similar characters in Japan
>and in China.
>
>Of course, it is possible to LOCALIZE Unicode so that it produces
>Japanese characters only or Chinese characters only. But don't we
>need internationalization?
>

I have been following this discussion for some time, despite the
(IMHO) obnoxious header :-).  I have been surprised that up until
now the 32-bit proposed standard (I no longer recall the OSI number)
has not been mentioned.  I personally would prefer this, for the
reasons stated above (japanese/chines collisions in Unicode).  Furthermore,
for research involving ancient egyption texts or other "obscure" languages,
16 bits even with some expandability would probably not be sufficient.

I personally would vote for support of 32-bit characters rather than 
Unicode, if anyone is able to scare up the docs on the proposed 32-bit
character standard.  This would allow Linux to avoid the comming
difficulties with chinese/japanese font collisions, and also keep it
out on the leading edge, rather than following Microsloth's somewhat ...
ah ... shall we say, questionable leadership in this area.

just my $0.02 worth.

Jean.
-- 
Jean Liddle                                 
Computer Science, Illinois State University  
e-mail:  jliddle@ilstu.edu                  
--------------------------------------------
Newsgroups: comp.unix.bsd
From: thomas@aeon.in-berlin.de (Thomas Wolfram)
Subject: Re: os-bs fixed (v1.35), yet another boot manager
Keywords: os-bs
Organization: Cities in Dust
Distribution: usa
Date: Mon, 21 Dec 1992 21:05:31 GMT

In <1992Dec21.154225.5681@rwwa.COM> witr@rwwa.COM (Robert Withrow) writes:

>In article <4345@elwood.prz.tu-berlin.de>, 
>wolf@blade.prz.tu-berlin.de (Thomas Wolfram) writes:

>| OS Boot Select (os-bs) is a replacement of the ordinary master boot
>| program.

>While you're here:

>Should os-bs be able to boot os2(hpfs) and 386bsd on the same disk.  Is
>there some trick to this?

It should be able to do that without tricks (if you have a primary OS/2 HPFS
partition, os-bs cannot boot from drives in extended partitions).

regards,
Thomas
-- 
Thomas Wolfram, thomas@aeon.in-berlin.de
EANTC, TU Berlin, wolf@prz.tu-berlin.de, +49 030 31421294
Xref: sparky comp.unix.bsd:10688 comp.os.linux:21889 comp.unix.pc-clone.32bit:911
From: jon@robots.ox.ac.uk (Jon Tombs)
Newsgroups: comp.unix.bsd,comp.os.linux,comp.unix.pc-clone.32bit
Subject: Re: ET4000/W32 and VESA VL-Bus
Date: 28 Dec 92 10:32:11 GMT
Organization: Robotics Research Group, Engineering Science Dept, Oxford, UK.
Originator: jon@diomedes.robots

In article <1hloneINNfnn@cbl.umd.edu> mike@starburst.umd.edu (Michael F. Santangelo) writes:
>>Also there are quite a number of S3 chips, which use EITHER VRAM or
>>DRAM:
>
>>	86C911		VRAM
>>	86C924		VRAM
>>	86C801		DRAM
>>	86C805		DRAM
>>	86C928		VRAM
>
>
>>What I am saying is that for 1028x768 in 70Hz and 1280x1024 you should
>>generally forget the DRAM based solutions. Even if they look good at
>>benchmarks; most of these benchmarks used a 640x480 resolution,
>>where the screen refresh only takes 25MB/sec, and the available
>>bandwidth for graphics operations is quite the same as for VRAM based
>>solutions. But if you use the DRAM based boards at 1024x768, 70Hz,
>>you'll see the difference.

The 801 is indeed DRAM based (60ns DRAM), For the 911 and 801 boards both
for 71Hz refresh at 1024x768 on a 13MHz ISA bus I get:

70MHz S3 911 (Actix GraphicsEngine70)
TOTAL    103781 lineStones
TOTAL     21777 fillStones
TOTAL     16997 blitStones
TOTAL   2580416 arcStones
TOTAL     83875 textStones
TOTAL     46797 complexStones
TOTAL     37496 xStones

S3 801 (Actix GraphicsEngine32)
TOTAL    107908 lineStones
TOTAL     42632 fillStones
TOTAL     31590 blitStones
TOTAL   2975512 arcStones
TOTAL    117562 textStones
TOTAL     92352 complexStones
TOTAL     64061 xStones

When I get back from holiday I'll repeat the benchmarks at several
different clock speeds and resolutions.  Possibly the 801 will be faster
at lower clock speed/resolutions, but it is still thrashing the VRAM based
Actix GraphicsEngine70, which was the fastest 911 based card I found.

--
 Jon                    <jon@robots.ox.ac.uk> (for a .vacation fortune)
                        "I got in today just as the sun was crashing"
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] NE/2000 and packet filter
Date: 30 Dec 1992 12:15:39 GMT
Organization: /etc/organization
Distribution: world
NNTP-Posting-Host: hal.gnu.ai.mit.edu


A couple more patches:

-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----
*** if_ne.c.~1~	Tue Dec 29 20:35:19 1992
--- if_ne.c	Wed Dec 30 07:05:58 1992
***************
*** 124,130 ****
--- 124,133 ----
  	u_char	ns_rxend;		/* receiver buffer end */
  	short	ns_port;		/* i/o port base */
  	short	ns_mode;		/* word/byte mode */
+ 	short	ns_rcr;
+ #if NBPFILTER > 0
  	caddr_t	ns_bpf;
+ #endif
  } ne_softc[NNE] ;
  #define	ENBUFSIZE	(sizeof(struct ether_header) + ETHERMTU + 2 + ETHER_MIN_LEN)
  
***************
*** 387,396 ****
  	outb (nec+ds_cmd, DSCM_NODMA|DSCM_PG1|DSCM_STOP);
  	outb(nec+ds1_curr, ns->ns_rxstart);
  	outb (nec+ds_cmd, DSCM_NODMA|DSCM_PG0|DSCM_START);
! 	if (ns->ns_if.if_flags & IFF_PROMISC)
! 		outb (nec+ds0_rcr, DSRC_AB|DSRC_PRO);
! 	else
! 		outb (nec+ds0_rcr, DSRC_AB);
  	outb(nec+ds0_dcr, ns->ns_mode);
  	outb (nec+ds0_imr, 0xff);
  
--- 390,398 ----
  	outb (nec+ds_cmd, DSCM_NODMA|DSCM_PG1|DSCM_STOP);
  	outb(nec+ds1_curr, ns->ns_rxstart);
  	outb (nec+ds_cmd, DSCM_NODMA|DSCM_PG0|DSCM_START);
! 	ns->ns_rcr = (ns->ns_if.if_flags & IFF_BROADCAST ? DSRC_AB  : 0) |
! 		     (ns->ns_if.if_flags & IFF_PROMISC   ? DSRC_PRO : 0);
! 	outb (nec+ds0_rcr, ns->ns_rcr);
  	outb(nec+ds0_dcr, ns->ns_mode);
  	outb (nec+ds0_imr, 0xff);
  
***************
*** 637,643 ****
  		outb(nec+ds0_tcr, DSTC_LB0);
  		outb(nec+ds0_rcr, DSRC_MON);
  		outb(nec+ds_cmd, DSCM_START|DSCM_NODMA);
! 		outb(nec+ds0_rcr, DSRC_AB);
  		outb(nec+ds0_tcr, 0);
  	}
  
--- 639,645 ----
  		outb(nec+ds0_tcr, DSTC_LB0);
  		outb(nec+ds0_rcr, DSRC_MON);
  		outb(nec+ds_cmd, DSCM_START|DSCM_NODMA);
! 		outb(nec+ds0_rcr, ns->ns_rcr);
  		outb(nec+ds0_tcr, 0);
  	}
  
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----

-- 
 \  /   Charles Hannum, mycroft@ai.mit.edu
 /\ \   PGP public key available on request.  MIME, AMS, NextMail accepted.
Scheme  White heterosexual atheist male (WHAM) pride!
Newsgroups: comp.unix.bsd
From: gtoal@pizzabox.demon.co.uk (Graham Toal)
Subject: Re: [386bsd] GNU malloc in favor of BSD malloc in libc - shall we vote?
Organization: Cuddlehogs Anonymous
Date: Fri, 1 Jan 1993 06:21:48 GMT

In article <1i0cnoINNiu2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
:In article <1993Jan1.001332.15123@serval.net.wsu.edu> hlu@eecs.wsu.edu
:(H.J. Lu) writes:
:> Another `feature' in GNU malloc is malloc (0) returns NULL.
:According to ANSI, malloc(0) is implementation-defined.  I believe some
:systems intentionally return a bogus(?) address so that sloppy programs
:don't have to think about it.
:
:Obviously, you can't write or read at the address returned by malloc(0)
:anyway; what difference can it really make?

It makes a difference when you realloc.  NULL is fine by me though.
Relying on a pointer to a piece of memory that you can't access seems
to me to be even more sloppy.

G
Newsgroups: comp.unix.bsd
From: gclarkii@NeoSoft.com (Gary Clark II)
Subject: Deliver, Where?
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 21 Dec 1992 23:29:22 GMT
Followup-To: comp.unix.bsd 
Keywords: deliver, archive site

Hello,

I'm trying to get away from sendmail here (no network, no need..).  I've
got smail working real well, but I need deliver.  I can get it to compile,
but it dumps core with a seg fault.  Before I go looking through the stuff,
does anyone know where I can find a port?

Gary Clark II (N5VMF)
gclarkii@tghost.gbdata.com
gclarkii@sugar.neosoft.com
{root@gbdata.com when the system is up....:(}



Newsgroups: comp.unix.bsd
From: tweten@wilbur.nas.nasa.gov (Dave Tweten)
Subject: Re: [386BSD] partitioning and other things
Keywords: partition, magic numbers
Organization: NAS Systems Division, NASA Ames
Date: Mon, 21 Dec 92 21:08:48 GMT

In article <1992Dec20.221431.12825@cs.cornell.edu> cchase@cs.cornell.edu (Craig Chase) writes:
>I have just installed 386bsd on my computer and have a few questions:

>2) I am currently running the os/2 2.0 boot manager which allows me to select
>	which operating system to boot.  Problem, it will not boot 386bsd for
>	me.  Is there another boot manager available that will work with
>	dos, os/2 and 386bsd?

There are two which have been posted in the past six months.  OS-BS
seems to be the most popular, judging from mentions on the net.  My
favorite is Booteasy, because it more closely matches my usage patterns.

OS-BS has a fixed default boot partition.  When it asks and you don't
answer, after a few seconds thats the partition that boots.  By
contrast, Booteasy uses the last chosen partition as the default.  Since
I reboot more often than I choose a different boot partition I find it
more convenient.

I believe that both are available from agate.berkeley.edu by anonymous
FTP.
-- 
---------------------------------------------------------------------------
Dave Tweten						tweten@nas.nasa.gov
NASA Ames Research Center, M/S 258-5			     (415) 604-4416
Moffett Field, CA  94035-1000				FAX: (415) 604-4377
From: usp@jif.berkeley.edu (USP Network)
Newsgroups: comp.unix.bsd
Subject: Problems with LP and SLIP
Date: 28 Dec 1992 00:34:05 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: jif.berkeley.edu

Hi,

	first of all let me congratulate the Jolitz and everybody who
made 386BSD possible. Thanks also to Amancio who helped me with the
X system.
	However, there are still two major problems I haven't been
able to solve:

1) lp driver: I installed the one by Tibor Sashegyi from  agate. It seems
to be very fast but it doesn't print correctly some large files (for
example, files produced by ghostscript). I read in this
newsgroup that some motherboards are not able to correctly respond to 
interrupts and decided to try the only driver I found which does not
use interrupts. This new one works fine (thanks to Andy Valencia) but
seems to be very slow. The speed I get from DOS (arghh :-) ) or
Interactive Unix is 6 or 7 times faster. That  means that when I have to
print a large document, it pays to reboot DOS only to do the printing
and then come back to BSD. Any idea what is wrong ??

2)SLIP (or com driver): I connected my box at home to a Sun machine in
my university through a leased line (awfully expensive here in Brasil
:-( and bought two V.32bis modems. The connection works but every now
and then I get the famous "SILO OVERFLOW" message. I have Chris'
multiserial driver installed but even at low speeds (1200 or 2400), I
still get the messages. I don't care about the messages but the
problem is that the slip connection sometimes hang in the middle of a
file transfer. I have read that a 16550 would help but:
	1) I think my internal modem doesn't have a 16550 (it is a
	   TurboModem V.32bis).
        2) File transfers work perfectly all right under DOS. Ok Ok, I
know that DOS is not a multitasking system but I just tested it under 
Interactive without any problems. In fact, the speed under Interactive
is higher than in BSD (0.86 kbytes per second against 0.8, with 9600 
and no compression). 

Oh, I have the patchkit installed, though I had to delete a "return;"
statement in patch 19 that prevented slip from working. What is wrong?
HELPPP!

Any help VERY appreciated,

Carlos Ruggiero (toto@uspfsc.ifqsc.usp.br or usp@jif.berkeley.edu)

PS: The Sun I'm  connected to is a Sparcstation 1+. I know this is not
the right place to ask this but... Has anyone got SLIP running at
14400 on a Sparcstation 1+?When I try to set the serial to 19200 (a
SPC/S board), there is no way to implement flow control and file 
transfers become very inefficient

Newsgroups: comp.unix.bsd
From: poirot@mickey.jsc.nasa.gov (Daniel Poirot)
Subject: Re: [386bsd] Kernel build dies, unref symbol _version
Organization: NASA Johnson Space Center
Date: Sat, 2 Jan 1993 00:48:17 GMT

In article <id.E4CW.XE@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Dec26.235116.3795@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> In article <17701@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>> >In article <BznK64.AGL@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
>> >>>"init_main.o: something about an unreferenced symbol _version"
>> >>>is there a standard fix for this?
>
>> >>Yeah, ATFP.  Add The Fine Patchkit.  This problem is fixed by patch #1.
>
>I did. It isn't. You have to "make newvers" to get a vers.c file to resolve
>this symbol. This should be documented. :->

Actually, shouldn't the Makefile target '386bsd' depend on 'vers.o'?
Wouldn't that solve the problem?  I think that a patch to the kernel
Makefile is in order.
-- 
Daniel Poirot           poirot@aio.jsc.nasa.gov
NASA JSC                "The mind is a terrible thing."
ER3                     tel: (713)483-8793
Houston, TX 77058       fax: (713)483-3204
From: jdevries@Apple.COM (Jeff DeVries)
Newsgroups: comp.unix.bsd
Subject: [386BSD] Virtual memory paging not working?
Date: 1 Jan 93 00:53:16 GMT
Distribution: usa
Organization: Apple Computer Inc, Cupertino, CA

I was using a program that displays the amount of memory in use after a
garbage collection.  Shortly after reaching slightly more than 6Meg, the
program quit saying "Ran out of memory".  I thought this was odd because
even though I have 8Meg of real memory I also have a 16Meg swap partition, 
which means I should be able to get roughly 24Meg (right?).  So...

1) I checked the disklabel and, yes, as0b was the swap partition and
   it was 16Meg (32k blocks).

2) I checked /etc/fstab and, yes, as0b was listed as the swap partition.

3) /etc/rc had a "swapon -a" command in it.

4) I tried to manually set swapon /dev/as0b and was told the device 
   was already busy (which I took as a good sign that /etc/rc works).

Since everything that I knew to look at seemed to be in order, I then
tried the following little program:

#define 4MEG 4000000L
main()
{
  int i;
  int *big = (int *) malloc(4MEG * sizeof(int));  /* should be 16Meg */
  if (! big)
    printf("oops!\n");
  else
    for (i = 0; i < 4MEG; i += 128) /* be nasty and hit every page */
      big[i] = i;
}

... which printed "oops!"

Is there something else I need to be doing to get virtual memory paging
to work?  Am I confused about what it should be doing?

Any help would be appreciated!

Jeff
jdevries@apple.com
From: jim@wft.stack.urc.tue.nl (Jim Rump)
Newsgroups: comp.unix.bsd
Subject: Re: [386bsd] happy new year
Date: 3 Jan 93 11:14:49 GMT
Organization: Baseline Labs. Eindhoven Holland
NNTP-Posting-Host: shark.wft.stack.urc.tue.nl
X-Newsreader: TIN [version 1.1 PL6]

David Dawes (dawes@physics.su.OZ.AU) wrote:
[deleted]
: 
: I assume the year is showing up as 1992 (6 Jan 1992 was a Monday).
: 
: The patch works for me, but both Andrew, Bruce (and I) are east of GMT/UTC
: while you are west (so the TZ sign will be different).  Anyone else
: tried these patches?  The results from someone at GMT might be
: interesting.
: 
: David
: ------------------------------------------------------------------------------

I applied the patch, and it works for me. My timezone is MET.
The time before the patch was "yesterday" 


--Jim.
Newsgroups: comp.unix.bsd
From: dwoakes@cix.compulink.co.uk (David Woakes)
Subject: Tape streamer with 386bsd
Reply-To: dwoakes@cix.compulink.co.uk
Date: Tue, 22 Dec 1992 14:53:00 +0000


Xref: sparky comp.unix.bsd:10641 comp.unix.questions:14977
From: rich@Rice.edu (& Murphey)
Subject: Re: Xfree86 Font directory problem?
Reply-To: Rich@rice.edu
Organization: Department of Electrical and Computer Engineering, Rice
	University
Date: Wed, 30 Dec 1992 06:45:35 GMT

>>>>> In article <9212300215.AA00524@deepthought.cs.utexas.edu>, DS1437@acspr1.acs.brockport.edu writes:
D> NNTP-Posting-Host: cs.utexas.edu

D>     I am having problems getting Xfree86 running, it seems to initiaize
D> the screen fine , but then switches back to text, and hangs the console
D> port (still can telnet in). I found out that there is an error that
D> the server is reporting but never showing, I can only get this error on
D> a system that is telneted in, it is:

D> failed to set default font path '/usr/X386/lib/X11/fonts/misc/,/usr/X386
D> /lib/X11/fonts/75dpi/'
D> Fatal server error:
D> could not open default font 'fixed'

The XFree86 1.1 server checks the font path  more thoroughly if you
set it in your Xconfig than if you use the default.  Try setting it:

FontPath "/usr/X386/lib/X11/fonts/misc/,/usr/X386/lib/X11/fonts/75dpi/"

and see if that helps.  We are working on improving this for the next
release.  Rich
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] where is libcompat.a when compiling games?
Organization: University of Utah Computer Center
Distribution: comp.unix.bsd
Date: Tue, 22 Dec 92 02:53:48 GMT

In article <1992Dec21.195624.25169@nwnexus.WA.COM>, levinson@halcyon.com (Don Levinson) writes:
|> when I try to compile the games in /usr/othersrc/games
|> it dies when trying to link each game because it cannot fint
|> libcompat.a, as far as I can tell there is no libcompat.a and
|> never has been. (I am at patchlevel 58 or whatever the current
|> is)

A simple libcompat.a is available from ref.tfs.com.

					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: deraadt@newt.cuc.ab.ca (Theo de Raadt)
Subject: 386BSD: kvm_mkdb patch, whoops, whoops.
Organization: little lizard city
Date: Thu, 31 Dec 1992 22:27:25 GMT

I errored in my patch to kvm_mkdb (my kvm_mkdb.c.old file was corrupt, not the
new one). Here's the right patch.

Problem was that if kvm_mkdb was given an argument, it would try to open the
file kvm_mkdb (ie. argv[0]) instead of argv[1].

*** kvm_mkdb.c.old      Thu Dec 31 15:26:09 1992
--- kvm_mkdb.c  Mon Dec 28 21:58:18 1992
***************
*** 71,77 ****
        argc -= optind;
        argv += optind;
  
!       nlistpath = argc > 1 ? argv[0] : _PATH_UNIX;
        nlistname = basename(nlistpath);
  
        (void)sprintf(dbtemp, "%s/kvm_%s.tmp", _PATH_VARRUN, nlistname);
--- 71,77 ----
        argc -= optind;
        argv += optind;
  
!       nlistpath = argc > 1 ? argv[1] : _PATH_UNIX;
        nlistname = basename(nlistpath);
  
        (void)sprintf(dbtemp, "%s/kvm_%s.tmp", _PATH_VARRUN, nlistname);

--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca
From: vince@jsrvx1.ucsf.edu
Newsgroups: comp.unix.bsd
Subject: Infinite reboots revisited.
Date: 21 Dec 92 23:45:14 GMT
Organization: University of California San Francisco

I've looked through the faq, and the article archives, but couldn't find a
clear answer to the infinite reboot problem. Could someone please e-mail me
the proper solution? Also, where do I find the current faq and bug reports?
I didn't see them in news.answers. T

Thanks in advance,

Vince Reed
UCSF Cardiothoracic Surgery
vince@jsrvx1.ucsf.edu
Newsgroups: comp.unix.bsd
From: adrian@rachel.ibmpcug.co.uk (Adrian Hall)
Subject: Re: Shitty NE2000 NFS performance problem fixed right (source code)
Organization: The IBM PC User Group, UK.
Date: Mon, 21 Dec 1992 13:00:56 GMT

Since I use the NE-2000 in rachel, I was rather gratified to see someone
addressing the problems in the NFS performance (and no doubt other areas)
of the driver.

	However, the file /sys/i386/isa/ic/ds3890.h seems to be lacking
the vital support for the identifier DSCM_SENDP. Now I have no idea what
value to give to this identifier.

	Perhaps the author of this worthy driver could post or e-mail a
copy of his ds3890.h file, or wherever he defines this identifier to the
net, or simply tell us what it is meant to be.

	Adrian
-- 
------------------------------------------------------------------------------
Adrian Hall				Telephone: +44 (0)81 863 1191
Connect Systems Manager			Fax:	   +44 (0)81 863 6095
The IBM PC User Group			Internet:  adrian@ibmpcug.co.uk
Newsgroups: comp.unix.bsd
From: gary@sci34hub.sci.com (Gary Heston)
Subject: Re: Almost Free Symbolic Links (source code)
Reply-To: gary@sci34hub.sci.com (Gary Heston)
Organization: SCI Systems, Inc., Huntsville, Al.
Date: Mon, 21 Dec 1992 18:48:56 GMT

In article <DERAADT.92Dec17125257@newt.newt.cuc.ab.ca> deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
|In article <id.J2UV.H5K@ferranti.com> peter@ferranti.com (peter da silva) writes:
|   In article <39777@hoptoad.uucp> curt@hoptoad.uucp (Curt Mayer) writes:
|   > this cruddy but complete hack answers one of the objections to symlinks:
|   > that they are slow, and cost an entire frag. symlinks of less than length
|   > 60 are stored in the inode itself.

|   How about generalizing this to put ALL files < 60 bytes in the inode, not
|   just symlinks?

|Because it screws up the alignment all the way through the file. It's nice
|to know that going a multiple of st.st_blocksize into the file and reading
|a multiple of st.st_blocksize bytes is going to be faster.

No, he ask about *file < 60 characters*, not the *first 60 characters of 
a file*.

A damn good idea too, I think. All those little one-line shell scripts,
the 20 character files (/etc/myname comes to mind) would no longer eat
a whole block, and access time would be *much* faster.

Now, if I can just figure out why 386bsd is hanging up on an fsck with
the rll controller....

-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.
"Data sheet: HSN-3000 Nuclear Event Detector. The [NED] senses the gamma
radiation pulse [from a] nuclear weapon." As if we wouldn't notice...
From: news@hrd769.brooks.af.mil (InterNet News)
Newsgroups: comp.unix.bsd
Subject: Re: New kernel on rachel.ibmpcug.co.uk
Date: 23 Dec 1992 13:56:32 -0600
Organization: Armstrong Lab MIS, Brooks AFB TX
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <Bzq5sq.5nF@ibmpcug.co.uk> adrian@rachel.ibmpcug.co.uk (Adrian Hall) writes:
:This driver is now currently set up as major device 16 in the kernel
:on rachel.ibmpcug.co.uk.
:
:Anyone think there is a call for a central "person" who gives out
:major device numbers to those developing device drivers?

If there is, I will do it.

:
:	Adrian
:-- 
:------------------------------------------------------------------------------
:Adrian Hall				Telephone: +44 (0)81 863 1191
:Connect Systems Manager			Fax:	   +44 (0)81 863 6095
:The IBM PC User Group			Internet:  adrian@ibmpcug.co.uk

TSgt Dave Burgess
NCOIC AL/MIS
Brooks AFB, TX
Newsgroups: comp.unix.bsd,alt.suit.att-bsdi