On Tue, Oct 02, 2001 at 10:35:14AM +0930, Daniel O'Connor wrote:
UUCP still gets used. It's one of the few sane ways to handle email in
a laptop environment when you're always connecting through different
dialups/ISPs. It has mostly fallen out of favour due to ignorance and
FUD. Which
Brandon D. Valentine wrote:
do intend to work on this. At the moment I sit daily in front of an SGI
Indigo2 running IRIX because it's better than Linux and integrates quite
well with our environment. I really want a FreeBSD workstation on my
desk, so I'll likely end up writing the patches
Mike Smith wrote:
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and should be reported to the vendor. (It should
also have
Hi Warner,
I hope you can point me in the right direction or directly
answer the question I have. I'm an active -CURRENT user and
have aquired a Compaq WL100 wireless nic which does not work
with the 'NEWCARD' options defined. In order to get my 3Com
card to work, I need these options since
Hello!
After upgrade to 3.5 to 4.3-stable we encoutered a problem
with our custom device connected to com-port. The device
accepts command strings and returns strings in response,
but under 4.3 it strangely does not respond to commands
that are longer than 15 bytes ( 16 with \r).
The device is
I tried to install current snapshot as of October 2, 2001 from
current.jp.FreeBSD.org, but it seems to fail at
sysinstall.c:installFilesystems().
The function installFilesystems() calls MakeDevChunk() of
lib/libdisk/create_chunk.c, which then calls mknod(2) via
MakeDev(). The error message I see
While Openoffice for BSD is still milestones away from compiling,
I tried to port the linux version of SO6.0 beta to FreeBSD.
I got it extracted, and could run setup.bin, which fails miserably:
79358 setup.bin RET read 4096/0x1000
79358 setup.bin CALL linux_mmap(0xbfbfcfac)
79358
On Tue, Oct 02, 2001 at 09:23:50PM +0200, Riccardo Torrini wrote:
Different behaviour from 4.4 to 5.0 of host command. Why?
Yes, I got finally delegation for reverse (with RFC 2317).
Yes, my -CURRENT is really old, but I'm reading this list... ;)
That's your problem.
You see that this has
You lose. Until someone writes a fallback for machines that don't
have the BIOS32 entry point for PCIBIOS, you are stuck.
Warner
No I don't. I knew I will get bitten by putting my comments at the end
of the long message, but I did it nonetheless :(. Anyway, here is shorter
and hopefully
On 03-Oct-2001 (14:14:57/GMT) Bernd Walter wrote:
Yes, my -CURRENT is really old, but I'm reading this list... ;)
That's your problem.
Pilot error :-( Ok, sorry for that.
You see that this has been fixed at least since a month:
ticso@cicely9 uname -v
FreeBSD 5.0-CURRENT #1: Tue Sep
All these solutions assume that everyone is wired up with IP
connectivity. The original questions was who uses UUCP?
Correct.
One answer is: those without IP connectivity.
Do you mean 'full-time IP connectivity', because if you can setup a UUCP
connection, you can just as easily setup a PPP
As you've already noticed, sysinstall basically tries to create the
device nodes it needs under the old assumption that /dev will be
mostly empty. Now that devfs is the default, phk needs to update
libdisk so that it doesn't attempt to make the device nodes in this
way. Fortunately, the person
* Jordan Hubbard [EMAIL PROTECTED] [011003 15:33] wrote:
As you've already noticed, sysinstall basically tries to create the
device nodes it needs under the old assumption that /dev will be
mostly empty. Now that devfs is the default, phk needs to update
libdisk so that it doesn't attempt to
sysinstall, by design, knows very little about devices. It uses
libdisk(3) as the abstraction for dealing with all disks in
particular.
* Jordan Hubbard [EMAIL PROTECTED] [011003 15:33] wrote:
As you've already noticed, sysinstall basically tries to create the
device nodes it needs under
* Jordan Hubbard [EMAIL PROTECTED] [011003 15:33] wrote:
As you've already noticed, sysinstall basically tries to create the
device nodes it needs under the old assumption that /dev will be
mostly empty. Now that devfs is the default, phk needs to update
libdisk so that it doesn't
Well, since I don't own libdisk(3) and had no idea why you'd be
addressing this to me unless you were still confused, I presumed you
were confused. In any case, you need to be talking to phk about this.
- Jordan
From: Alfred Perlstein [EMAIL PROTECTED]
Subject: Re: current install failure
On Wed, Oct 03, 2001 at 03:58:06PM +0200, Martin Blapp wrote:
79358 setup.bin RET close 0
79358 setup.bin PSIG SIGSEGV SIG_DFL
79358 setup.bin NAMI setup.bin.core
BTW: This is CURRENT from today with a old linux base installed.
What if you try it with linux_base-7?
--
Andrew Gallatin wrote:
Thyer, Matthew writes:
Now xterm 1 has the message yp_first: clnt_call: RPC: Timed out
as its first line and xterm 2 has two of these messages.
The problem is that there is no global caching of NIS maps. Each app
maintains its own cache..
Since these are
At 1:52 AM +0900 10/3/01, Hajimu UMEMOTO wrote:
On Tue, 2 Oct 2001 12:30:33 -0400
Garance A Drosihn [EMAIL PROTECTED] said:
drosih The print queue for 'lp' on oink refers to a remote machine that
drosih is named neutron. That hostname maps to an IPv6 address. Thus,
drosih lpq/lpr/lprm
Kris Kennaway wrote:
On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote:
This may sounds strange, but as I don't actually recall seeing any actual changes to
burncd unless i missed something in my cvsup
early this morning CDT...
I just decided to give it another try before booting
Thyer, Matthew writes:
Now xterm 1 has the message yp_first: clnt_call: RPC: Timed out
as its first line and xterm 2 has two of these messages.
What's really fun is when you've got a rack or two of machines which
are NIS clients and their switch blows out overnight. As soon as they
Kazutaka YOKOTA wrote:
Is there any way for the loadable module to detect if
the kernel is configured for SMP or UP?
There is a global variable, ncpu. Its name may have changed
recently, so you will want to look at the SYSCTL() stuff in
/sys/i386/i386 to be sure.
-- Terry
To Unsubscribe:
All these solutions assume that everyone is wired up with IP
connectivity. The original questions was who uses UUCP?
One answer is: those without IP connectivity. Part of the problem
here I suspect is that the people who develop and maintain FreeBSD
live a life where a T-3 into your livingroom
sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440
/R/stage/image.kern 8 fd1440
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 1216 sector(s) in last cylinder unallocated
Nate Williams wrote:
POP and IMAP (I think) will lose all the envelope information,
You've been listening to Terry too long. It's certainly not the case,
although I've decided to quit arguing with Terry, since it's an
excercise in futility. No matter what you say, he'll either change the
POP and IMAP (I think) will lose all the envelope information,
You've been listening to Terry too long. It's certainly not the case,
although I've decided to quit arguing with Terry, since it's an
excercise in futility. No matter what you say, he'll either change the
subject or
This may sounds strange, but as I don't actually recall seeing any actual changes to
burncd unless i missed something in my cvsup
early this morning CDT...
I just decided to give it another try before booting into the kernel built this
morning, and it seems that it was a world issue,
and not
D'ya think it might be time for a 3rd floppy?
On Wed, 3 Oct 2001, Jordan Hubbard wrote:
sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt
1440 /R/stage/image.kern 8 fd1440
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block
Julian Elischer wrote:
See above. fetchmail + pop works fine. I've been get all of my envelope
information, and there is no worries.
This has noty been the case where I have seen..
This requires that you have a mailbox set up on the server which can
'encode' all of the envelope
Interestingly, Microsoft Exchange is one of the few commercial
SMTP servers that can handle more than a few hundred ETRN based
virtual domain instances. Go figure...
Any Q-Mail based solution using the commonly available ETRN patch also
scales well, although you have to 'roll your own'
On Wed, 3 Oct 2001 15:42:57 -0400, Kenneth Culver [EMAIL PROTECTED] said:
I was wondering if anyone had thought of implementing the above ioctl. Right
now from what I can tell, (from wmnet, and netstat) all stats for a network
device are kvm_read out of the kernel.
These applications
On Wed, Oct 03, 2001 at 02:34:51PM -0600, Lyndon Nerenberg wrote:
Do you mean 'full-time IP connectivity', because if you can setup a UUCP
connection, you can just as easily setup a PPP connection over the same
medium, giving you IP connectivity.
True, but there's a lot more
Do you mean 'full-time IP connectivity', because if you can setup a UUCP
connection, you can just as easily setup a PPP connection over the same
medium, giving you IP connectivity.
True, but there's a lot more infrastructure overhead involved in
setting up a group of disconnected machines via
Sure, I just don't have time to work on this right now.
- jordan
D'ya think it might be time for a 3rd floppy?
On Wed, 3 Oct 2001, Jordan Hubbard wrote:
sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt
1440 /R/stage/image.kern 8 fd1440
On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote:
This may sounds strange, but as I don't actually recall seeing any actual changes to
burncd unless i missed something in my cvsup
early this morning CDT...
I just decided to give it another try before booting into the kernel built
On Wed, Oct 03, 2001 at 12:55:08PM -0600, Nate Williams wrote:
Tell me, is your mail compliant with the non-disclosure of Bcc:
recipients requirement? If fetchmail doesn't strip the tunneling
headers (it doesn't), then the headers disclose Bcc:'ed
recipients to anyone who chooses to
36 matches
Mail list logo
