[no subject]

2002-03-10 Thread Charlie Root

Subject: Mail::Internet test subject


This is a test message that was sent by the test suite of
Mail::Internet.

Testing.

one

>From foo
four

>From bar
seven

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: I am running out of PTYs and I shouldn't be.

2002-02-26 Thread Charlie ROOT

> > `sh MAKEDEV ptyX` (where X is each of the numbers 1 through 7)
>
> Doesn't really matter.
> What is this set to ? :
>
>   pseudo-device   pty #Pseudo ttys
>
> Note that you can optionally add a number to the end of this option.


Currently this line is set like this:

pseudo-device   pty

with no number arguments.  Are you sure that I need to do this ?  When I
ran my tests on my laptop, I increased maxusers to 128 and made all the
/dev files, but I _did not_ add a number argument to the above line, NOR
did I add anything to /etc/ttys

Also, I did not rebuild screen - but nevertheless I was able to start 6
screens and create about 40 new screens on each of them, for a total of
240 or so screens opened  ...

So the question is:

How come on an identical environment (in terms of devices created, and
settings in the kernel) my laptop can create a huge amount of screens -
almost as many as the 256 pty device files in /dev, but on my server,
which is running all sorts of other items like http and ssh and postgres,
blah blah, I run out of ptys prematurely ?

thanks,

PT


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



I am running out of PTYs and I shouldn't be.

2002-02-25 Thread Charlie ROOT


I have recompiled my kernel with:

maxusers128

And have confirmed that that is indeed the case by checking the value in
`sysctl`.

Further, in addition to the 16 pty device files that come in /dev by
default, I have created all 256 of them by running the commands:

`sh MAKEDEV ptyX` (where X is each of the numbers 1 through 7)

And I have verified that all those devices are there, and have reasonable
major/minor numbers with the `ls` command.

So I am rather confused that I am running out of PTYs - I get an error
message from `screen` "No More PTYs." - and I am nowhere near to using up
all the PTYs.  I have a total of 307 processes on the machine, of which
roughly 100 are httpd processes, add to that another 20 or so for system
items, and you are left with a worst case scenario of about 180 PTYs in
use.

However, in reality, most of the other processes are other daemons and
programs.  I suspect I am using _maybe_ 32 or so PTYs.



I have set up a laptop to test, and did the same things to it - set
maxusers to 128, and built all the PTY devices in /dev, and I kept
creating new screens over and over until I hit about 240 of them and the
machine crashedso what gives ?  Why am I hitting a very low wall with
PTYs on this machine ?

I am happy to give out more information about the machine, just not sure
what else would be useful.

Many thanks,

PT


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Should URL's be pervasive.

2001-09-04 Thread Charlie Root

> All of this started with the quest for URIs being useable everywhere.

It's a stupid quest, for reasons others have pointed out.

> > When this isn't possible or
> > reasonable, it's not only difficult but *wrong* to abstract.
>
> I never said this was trivial.  We (which includes me) tried to start
> such a project at Amiga (Commodore) - It was well before HTTP was so
> popular.  The goal was to hide the specifics and provide a single operation.
> FTP support was via a local cache while the file was open and if you did
> a write, it would write back the file at close time.

See above. There's a reason AFS hasn't replaced NFS.

> I was not asking for a magic bullet.  (Well, not this time :-)
> I was asking that the OS support reading and/or writing of data (whatever
> that may be) to a file/filehandle that was created via a standard
> system call.

Pipes, named or otherwise.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Should URL's be pervasive.

2001-09-04 Thread Charlie Root

> What I was trying to say is that there is no reason that I should care
> if the file is local or not.

You do need to know if the file is local or not. You need to know
for security. You need to know because files behave differently on
different machines. You need to know because file structures don't
map from one machine to another. You need to know because
differing protocols allow you do to very different things to
files. You need to know because performance varies dramatically
depending on where the file is located.

> Just as the OS support having multiple storage devices and media and the
> software does not need to know if the file is on a SCSI or IDE disk or if
> it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if
> it is local or on the machine beside it or on the machine on the other side
> of the world?

The OS support of multiple device types exists because it is
possible and reasonable to abstract each of those device types
into a single "virtual" type. When this isn't possible or
reasonable, it's not only difficult but *wrong* to abstract. There
are way too many things you can do with a local file that you
can't do with a remote file to allow this abstraction.

> Anyway, the point is that a file that I can access should be a file I
> can access via VI or MORE or EMACS or GREP or any other tool without
> having those tools each having FTP and HTTP and SSH support built in to
> them.  The OS should handle it.

No it should not. It's not reasonable for the *operating system*
to know about every damned protocol that someone decides would be
a just peachy way to access a file. Hell, it's not even practical.

The idea of universal abstraction just does not work. If you think
otherwise, I suggest you start coding and stop bothering the rest
of us until you've made it work.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



No Subject

2001-08-24 Thread Charlie Root

Subject: Mail::Internet test subject


This is a test message that was sent by the test suite of
Mail::Internet.

Testing.

one

>From foo
four

>From bar
seven

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



subscribe alexey@nsl.ru

2000-08-08 Thread Charlie ROOT

subscribe [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



smb printer trouble

2000-05-16 Thread Charlie Root

I wrote a simple filter to print to an nt print queue through
the smbclinet. It tests to see if the file is postscript or
text, and if it is text it sends a control code to tell the 
printer to do the lf->crlf conversion. 

My problem is that the '\' escapes in the first line get clobbered.
for example, if I print this printcap:

 begin printcap 
lp:\
:sh:\
:lp=/dev/lpt0:\
:sd=/var/spool/output/lpd/lp:\
:lf=/var/log/lpd/lpd.log:

lplaser:\
:sh:\
:lp=/dev/null:\
:if=/root/filters/smb-filter:\
:sd=/var/spool/output/lpd/lplaser:\
:lf=/var/log/lpd/lpd.log:
 end printap 

the entire entry for "lp" will be on one line, but the "lplaser"
entry will print out like it is supposed to.

I know why it is doing it, however I don't know how to fix it. Any
help will be appreciated (script is below). 

Thanks,
James

 begin smb-filter 
#!/bin/sh

# Input filter to print to a NT print queue, requires smbclient.
#
# Author: James Halstead, e-mail: [EMAIL PROTECTED]
#
# Read stdin to a temp, make sure to determine the print type, then use
#   smbclient to print to the nt queue.


SERVER=
PRINTER=cw
TEMP=/tmp/smbprint

TEMP=`mktemp -q $TEMP.XX`

read firstline
first_two=`expr "$firstline" : '\(..\)'`

if [ "$first_two" != "%!" ]; then
  printf "\033&k3G" > $TEMP 
fi

#lets see, copy the firstline to temp, cat the rest to the temp, 
# make one ugly command to print the file to the smb printer then
# rm the temp file.

echo "$firstline" >> $TEMP && cat >> $TEMP &&\
/usr/local/bin/smbclient $SERVER\\$PRINTER -UGUEST -N\
 -c"print $TEMP" &&\
rm -f $TEMP >/dev/null && exit 0

exit 1
 end smb-filter 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: problems with "-O -pipe" in guile port

2000-04-17 Thread Charlie Root

>From [EMAIL PROTECTED] Mon Apr 17 11:07:13 2000
>To: Martin Cracauer <[EMAIL PROTECTED]>
>Subject: Re: problems with "-O -pipe" in guile port 
>Cc: James Halstead <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED]
>In-reply-to: Your message of "Mon, 17 Apr 2000 14:24:36 +0200."
>   <[EMAIL PROTECTED]> 
>References: <[EMAIL PROTECTED]>  
><[EMAIL PROTECTED]> 
>Date: Mon, 17 Apr 2000 09:11:52 -0600
>From: Warner Losh <[EMAIL PROTECTED]>
>
>In message <[EMAIL PROTECTED]> Martin Cracauer writes:
>: In <[EMAIL PROTECTED]>, James Halstead wrote: 
>: > /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../libguile -O 
>-pipe -Wall -Wpointer-arith -Wmissing-prototypes  -c qtmds.s
>: > rm -f .libs/qtmds.lo
>: > cc -DHAVE_CONFIG_H -I. -I. -I../libguile -O -pipe -Wall -Wpointer-arith 
>-Wmissing-prototypes -c qtmds.s  -fPIC -DPIC -o .libs/qtmds.lo
>: > 
>: > *** dies here ***
>: 
>: No error messages?
>
>If it is like the hangs that I've seen with g++, no.  There are not
>error messages.  It just hangs and eats all CPU.  I've not had a
>chance to track this down.
>
>Warner
>
I can't remember exactly but i think that the compiler was in the wait state and not 
taking any process time. I could be wrong. could check if sombody wants me too.

I don't know if martin knows but the workaround is to remove te -O.
If you did then ignore that last line ;)

James


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



gcc command line ordering question

1999-12-29 Thread Charlie Root

I have a tiny little snippit of code here (test.c):

char ldap_init();
int main(int argc, char **argv)
{
  ldap_init();
  return 0;
}

I expect (want) a runtime error but I do expect it to compile when
linked with the openldap libraries. Here's my quandery:

vv# gcc -L/usr/local/lib -I/usr/local/include -lldap -llber test.c
/tmp/ccj67244.o: In function `main':
/tmp/ccj67244.o(.text+0x7): undefined reference to `ldap_init'

Very odd... but if I changed the ordering of the arguments:

vv# gcc -L/usr/local/lib -I/usr/local/include test.c -lldap -llber
vv#

It compiles fine. I thought gcc proccessed files in the order in which
they appeard? I further thought that the only difference between
specifying a fullname and using -l was that -l surrounding the name
with lib*.a and searched multiple directories. If thats all true why
would the ordering matter here?

-Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message