Re: __fpclassifyd problem

[Nate Williams]

[ add compatability hacks to libm ]
> > We tried this at usenix, but it still didn't work.  Obviously there is more
> > going on.
> > 
> > Before anybody goes and bumps libraries etc, it would be useful to know if
> > running a statically linked jvm will work on -current.
> 
> This sounds like a good plan, though it should be noted that statically 
> linking the jvm executable will reder it useless since it won't be able
> to dl_open any of the essential JNI modules.

Not just the JNI modules, but basically *all* the modules are dl_opened,
so a staticially linked modern JVM can't realistically be created.

The last time we were able to create a static JVM was JDK1.1.  I spent
many weeks attempting to create one for 1.2, and finally gave up.



Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sendmail: no local mailer

[Nate Williams]

> > > evantd> Sendmail has not been working on my system for some time now. I
> > > evantd> can't say exactly how long, but my guess is that it broke when I
> > > evantd> upgraded to RELENG_5_0. This is how sendmail is invoked (by
> > > evantd> default) and it's output.
> > > 
> > > evantd> # sendmail -L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost
> > > evantd> 451 4.0.0 No local mailer defined: Bad address
> > > evantd> 554 5.0.0 QueueDirectory (Q) option must be set
> > > 
> > > /etc/mail/sendmail.cf is a bogus (empty?) file.  One way to fix this is:
> > > 
> > > cd /etc/mail
> > > mv sendmail.cf sendmail.cf~bogus
> > > make
> > > make restart
> > 
> > This happened on one of my -stable boxes lately when doing a upgrade
> > using buildworld.  For some (unknown) reason m4 bombed out and created
> > an empty .cf file.
> > 
> > I fixed it by doing something similar to what was done above, although
> > why m4 failed is a mystery
> 
>   Some patch:
> 
> --- /usr/src/etc/sendmail/Makefile.orig Wed Apr  2 23:51:19 2003
> +++ /usr/src/etc/sendmail/Makefile Wed Apr  2 23:51:50 2003
> @@ -1,7 +1,7 @@
>  # @(#)Makefile 8.19 (Berkeley) 1/14/97
>  # $FreeBSD: src/etc/sendmail/Makefile,v 1.21 2002/07/29 09:40:06 ru Exp $
> 
> -M4=  m4
> +M4=  /usr/bin/m4
>  CHMOD=   chmod
>  ROMODE=444
>  RM=  rm -f
> 

This shouldn't be necessary, since m4 is in the path in buildworld, is
it not?  Otherwise, we wouldn't be able to run make, cc, or any other
tools.



Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sendmail: no local mailer

[Nate Williams]

> evantd> Sendmail has not been working on my system for some time now. I
> evantd> can't say exactly how long, but my guess is that it broke when I
> evantd> upgraded to RELENG_5_0. This is how sendmail is invoked (by
> evantd> default) and it's output.
> 
> evantd> # sendmail -L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost
> evantd> 451 4.0.0 No local mailer defined: Bad address
> evantd> 554 5.0.0 QueueDirectory (Q) option must be set
> 
> /etc/mail/sendmail.cf is a bogus (empty?) file.  One way to fix this is:
> 
> cd /etc/mail
> mv sendmail.cf sendmail.cf~bogus
> make
> make restart

This happened on one of my -stable boxes lately when doing a upgrade
using buildworld.  For some (unknown) reason m4 bombed out and created
an empty .cf file.

I fixed it by doing something similar to what was done above, although
why m4 failed is a mystery



Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libthr and 1:1 threading.

[Nate Williams]

> > You should notice marked interactivity and UI latency improvements with
> > threaded GUI apps over libc_r because GUI threads will generally no longer
> > be blocked when disk I/O and blocking I/O occurs.  For example,
> > applications like Open Office, Netscape, et al, really get a lot better
> > with 1:1.  Likewise, non-interactive applications that are disk
> > I/O-intensive, such as mysql, will also perform substantially better
> > because a thread that hits blocking using an interface that doesn't
> > support non-blocking I/O (such as the file system) won't clog up the
> > application.
> 
> Is the disk I/O really that big of an issue?

In my experience, yes.  Disk I/O is blocking, since you can't reliably use
non-blocking descriptors for disk I/O, since you don't know if it will
block, and for how long.

Again, in my experience, it was much easier to setup non-blocking
networking descriptors, since unlike disk I/O, you needed to deal with
things not get written at the application.  With disk I/O it was much
harder to determine what if anything got written if you did non-blocking
writes, and if you needed things written both effeciently and reliably
to disk, you *have* to know how much was written successfully, and
byte-at-a-time I/O is simply un-acceptably slow.

I'm sure others have run into this problem as well.

> It seems to me that maybe the correct fix for this is to use
> AIO instead of non-blocking I/O, then?

AIO is non-portable.



Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Cordless Keyboard + Mouse

[Nate Williams]

> > > Has anyone been able to get the Logitech Cordless Elite Duo, or any
> > > cordless kb/mouse combos to work?
> > 
> > I've got the older Logitech 'Natural' wireless keyboard + wireless mouse
> > working fine.  I've had it for almost 3 years now, and aside from having
> > to change batteries every 4-6 months it's been rock solid.
> > 
> > > I have the Cordless Elite Duo however the system only detects my
> > > keyboard, and I have to use a corded mouse. I have been searching around
> > > and yet to find anything on getting the combos to work.
> > 
> > I didn't have to do anything to get it to work for me.  I plugged the
> > mouse connector into the mouse slot, the keyboard into the keyboard
> > slot, and all is well.
> > 
> 
> My combo uses a single reciever for both devices, sounds like you have
> two?

Single receiver, but two cords coming out of it.

> dmesg shows that both the mouse and kb were detected, mouse as ums0 and
> kb as ukb0. XFree is set to use /dev/sysmouse, but dies with no core
> pointer if I dont use the corded mouse.

I hard-code the mouse and don't use sysmouse.

> ukbd0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1
> ums0: Logitech USB Receiver, rev 1.10/13.10, addr 2, iclass 3/1

Mine shows us as a ps/2 mouse.  Is this a USB setup?  Mine's a normal
non-USB setup.



Nate

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

Re: Cordless Keyboard + Mouse

[Nate Williams]

> Has anyone been able to get the Logitech Cordless Elite Duo, or any
> cordless kb/mouse combos to work?

I've got the older Logitech 'Natural' wireless keyboard + wireless mouse
working fine.  I've had it for almost 3 years now, and aside from having
to change batteries every 4-6 months it's been rock solid.

> I have the Cordless Elite Duo however the system only detects my
> keyboard, and I have to use a corded mouse. I have been searching around
> and yet to find anything on getting the combos to work.

I didn't have to do anything to get it to work for me.  I plugged the
mouse connector into the mouse slot, the keyboard into the keyboard
slot, and all is well.


Nate

ps. I'm running -stable, though I doubt it matters much.

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

Re: Poweroff problem with IBM ThinkPad T21 (ACPI?)

[Nate Williams]

> I just put 5.0-DP2 on my IBM ThinkPad T21 (which I can finaly use, 4.x
> was pretty bad since only one of the two pcmcia slots worked, and
> numerous other problems, forcing me to use windows) and have been very
> very happy with it.

Really?  I ran 4.X on my T21 for over a year with no problems
whatsoever.  4.X was usable, unlike 3.X, which was a complete mess.

> I only have 1 problem that I have been completely unable to solve.
> 
> If I power off the laptop (shutdown -p now, or halt -p), approximately
> 60-63 minutes later the laptop will power back on (I live in Los
> Angeles, and so it powers back on in my laptop bag during my commute
> home, so when I get home it's about to overheat) all by it's self.  This
> is pretty odd.  I have found no way to make it not do this.

Hmm, this sounds like a BIOS setting for wakeup on LAN/phone events.
You might check the bootup to see if 'Wake-On-Lan' is set or somesuch.

Otherwise, I have no idea...


Nate



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

Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation

[Nate Williams]

> I've recalled that FreeBSD used RTC to determine base memory size in
> old days.  I've tested this method on my machines and confirmed it's
> working well.

If this is done, then FreeBSD won't work on many laptops and other
desktops, which report 640K for memory, but the BIOS actually steals
some of the memory for things like APM, so when the VM86 call is done
the reported memory size is actually like (like 637K or something).

This change may break FreeBSD on these 'newer' hardware as well.



Nate

> I'll commit this coming weekend if no objections.
> 
> Thanks
> 
> Index: machdep.c
> ===
> RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
> retrieving revision 1.541
> diff -u -r1.541 machdep.c
> --- machdep.c 5 Oct 2002 14:36:14 -   1.541
> +++ machdep.c 21 Oct 2002 15:27:02 -
> @@ -1284,8 +1284,14 @@
>   /*
>* Perform "base memory" related probes & setup
>*/
> - vm86_intcall(0x12, &vmf);
> - basemem = vmf.vmf_ax;
> + if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)<<8)) > 640)
> + basemem = 640;
> +
> + if (basemem == 0) {
> + vm86_intcall(0x12, &vmf);
> + basemem = vmf.vmf_ax;
> + }
> +
>   if (basemem > 640) {
>   printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
>   basemem);
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

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

Re: devfs oddity?

[Nate Williams]

> >> > In message <[EMAIL PROTECTED]>, Steve Kargl w
> >> > rites:
> >> > >root[208] cdcontrol play
> >> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c
> >> > >cdcontrol: /dev/cd0cc: No such file or directory
> >> > >
> >> > >Why is an extra "c" appended to cd0c?
> >
> >The first "c" is part of the standard name for the whole of a (labelled)
> >disk device.
> 
> It's not any "standard name".  It is a convention used on a minority
> of UNIX platforms out there, and it is certainly not "standard" even
> for BSD based systems.

It's certainly standard on every BSD based system I've ever used, which
goes *WAY* back.  (Every BSD OS vendor has done it this way, including
Sun, DEC, HP, etc...)

> It is also illogical, counter-intuitive and prone to mistakes.

Then every standard is the same, since standards by their very nature
are illogical.  Doing something the same way is illogical?

(If you haven't figured it out, I disagree *strongly* with the above
statement.)

> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
^^^
Which also used 'c' as the entire 'whole' of a labelled disk device.



Nate

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

Re: HEADS UP: UCONSOLE option has been phased out

[Nate Williams]

> > However, it was required for some X applications to work correctly,
> > which is why it was still being used.
> 
> No, it's just required for them to work when run by unprivileged
> users.

Things like xconsole *are* run by unprivileged users.



Nate

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

Re: HEADS UP: UCONSOLE option has been phased out

[Nate Williams]

> This is a JFYI that the UCONSOLE kernel option has been phased
> out as insecure.  Fix your configs.

Umm, it's listed as insecure in the every config file, so you're not
saying anything that wasn't already known.

However, it was required for some X applications to work correctly,
which is why it was still being used.

What is being done now to ensure those applications still work?  Did you
provide patches to the XFRee86 team for FreeBSD?




Nate

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

Re: The sendmail discussion...

[Nate Williams]

> > (my company demands
> > that all software I write, including in my own free time, is copyright by
> > them)
> 
> You need to move to California, where this is against the law.

Every California company I've worked for has made me sign a statement
with the above stipulation.  In order to avoid this, I was required to
specifically describe projects I worked on prior to my employment that
were immune from these restrictions.

It may be illegal, but I'm guessing that you and I don't have the legal
resources to fight it in court should an occasion if the employer wanted
to be enforce the statement, which was signed voluntarily.



Nate

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

Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )

[Nate Williams]

> > "Bruce A. Mah" <[EMAIL PROTECTED]> writes:
> > > Differences of opinion on naming aside...the branch isn't supposed to
> > > last long at all.  The point is to provide a slightly polished snapshot
> > > to the wider developer community.  We can't do the QA/releng work on
> > > HEAD without calling for a code freeze (which we early on decided that
> > > we would *not* do).
> > 
> > Then you don't need a branch, you just need a simple tag, and you can
> > slide it forward if something needs fixing, and remove it after rolling
> > and shipping the snapshot. 
> 
> No, in this case that doesn't help.  What we want is to grab a stable
> moment, then to allow development to continue.  However, we may then want
> to tweak that stable moment without impinging on development, which
> requires a branch.

Not necessarily.  What we've done at work is *NOT* create a branch
unless absolutely necessary.  The only time a branch is requires is *if*
a file changes out from underneath the developer *AND* it that files
needs modifying but *must not* contain that same change.

We play it by ear, since in almost all cases, the change can be made to
any necessary file(s) and the file(s) updated by hand.  Otherwise, often
the change that happens are necessary to merge into the build, so we do
an update.

Only in very rare cases do we run into a problem where we have to create
a branch.  In that case, the developer responsible for the release
creates a branch from his checked out tree (there's no law against
creating a branch from sources that are older than the HEAD), and then
makes any necessary changes.

It's *not* that hard to do.  Otherwise, once the release is made using
the files, a point-tag is laid down and we've saved the hassle of the
branch.

> The QA/releng work requires us to modify the stuff being released
> following the branchpoint.

See above.



Nate

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

RE: BESTDEB: your Postfix installation is hosed

[Nate Williams]

> > You are reflecting messages back to a mailing list with
> > thousands of subscribers.
> > 
> > Cut it out.
> > 
> > -- Terry
> 

> Peter has applied the Big Hammer of Death to the problem for now, so
> it should be stopping soon if not already.

Thanks Peter


Nate

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

Re: gcc3.x issues

[Nate Williams]

> : How many MB does your flash card where you're installing
> : FreeBSD have on it?
> 
> I've installed a subsetted FreeBSD onto a 8MB CF card.  For normal
> FreeBSD (as oppsoed to pico), the smallest amount of space you need is
> about 6.9M, and that can be stripped down to about 5M with compression
> and custom rc files with network stuff.
> 
> However, to do a standard install, the minimal installation takes
> about a 128M 196M part (but I haven't tried it lately).

I've got 4.5-PRE pico on a floppy that boots on a 486/66, but it's
*really* tight (<10k available).  If I login to the box remotely and try
to run anything, it kills the login process so it's pretty useless.

With another 4-8MB of memory, the box would actually work pretty well as
a dedicated wireless firewall/router/snooper.  For now, it works pretty
good as a wireless router/simple packet filter. :)


Nate

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

Re: uucp user shell and home directory

[Nate Williams]

> > I don't get your point - what is wrong with having it a port?
> 
> Well, here's one reason:
> 
> 1) Remove all the network interfaces from your system (Ethernet,
> PPP, SL/IP, etc). 
> 
> 2) cd into /usr/ports and try to build UUCP.
> 
> Unless you have a prepopulated /usr/ports/distfiles, it won't work.
> Requiring IP connectivity to bootstrap software on a machine
> that doesn't have IP connectivity is a non-starter. Yes, you can
> install from the CDROM, but there will always be cases where you
> can't do this (media errors, lack of CD, etc.)

Umm, how did you get FreeBSD installed in the first place, if you didn't
have IP connectivity and no CDROM?

IP connectivity is necessary to get the OS installed, so this is a moot
point.

And, if you want to maintain the UUCP software, it's as easy to do in
the prot as it is in the OS, and is in fact *easier* to maintain as a
port w/out IP connectivity since you can submit patches via email, but
you can't commit changes to the CVS tree via email as easily.



Nate

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

Re: uucp user shell and home directory

[Nate Williams]

> 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 connection over the same
medium, giving you 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 is just something you
> take for granted.

Not so.

> UUCP has many valid uses. Even today. If you don't understand the
> software, that's fine with me. Just don't use your ignorance as
> an excuse to dike the software out. Or more precisely, admit
> you want to rip the code out because you don't understand what
> it is, rather than making up specious excuses for it's removal.

Cheap shot.  Some of us who favor diking out UUCP were heavily involved
with the Internet back when it was essntially Usenet over UUCP.  :)

I favor diking it out because there are in almost all cases (but not
necessarily *ALL* cases) a better solution that exists.

Because of this, I don't believe that UUCP is a mainstream solution, and
therefore doesn't belong in the mainstream release.  It *is* still
available as an add-on port, so those who need it can still get it, but
it doesn't clutter up the regular distributions.  Finally, the security
issues make it a non-starter to keep in the default distribution.



Nate

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

Re: uucp user shell and home directory

[Nate Williams]

> 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' release and integrate
the patch separately.  However, this is arguably not much harder than
configuring the ETRN portions of the configuration.




Nate

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

Re: uucp user shell and home directory

[Nate Williams]

> > > 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 simply overwhelm you with useless/unrelated material until
> > you simply abandon any hope of trying to give out useful information.
> 
> > See above.  fetchmail + pop works fine.  I've been  get all of my envelope
> > information, and there is no worries.
> 
> Perhaps you aren't using it in "multidrop" mode, for virtual
> domain delivery?

That's correct.  I'm not, which is something POP was never intended on
doing.  (However, in this case, I am my own ISP, since I have a
full-time connection with my own mailserver and domain.)  I'm using
fetchmail + pop to fetch my already delivered email so that I can also
retrieve email securely when on business trips.  For single users, this
works great.

> 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 look.

It sure is, because it's the responsibility of the mail sending program
to handle this.  Fetchmail is a mail retrieval program, so it's only job
is to fetch the mail that is already delivered to me.

> PS: I'm surprised you didn't mention the "finger" or the "PPP
> linkup script" methods.

Finger is an abomination, and PPP linkup scripts are really only useful
for certain kinds of accounts.  When I'm away on business, why dialin
when I have a perfectly good internet connection that doesn't use PPP?


Nate

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

Re: uucp user shell and home directory

[Nate Williams]

> 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 simply overwhelm you with useless/unrelated material until
you simply abandon any hope of trying to give out useful information.

> SMTP is a PUSH operation..
> 
> so for a PULL operation that can handle envelope information (e.g. BCC)
> you need UUCP

See above.  fetchmail + pop works fine.  I've been  get all of my envelope
information, and there is no worries.

For 'fetching' email, fetchmail is a very good solution.  However, there
is also another fairly trivial solution that works well, *IF* you have a
static IP address.

ETRN also is a good 'fetch' mechanism, if your ISP sets up MX records
for you.  When you come up, you simply telnet into your ISP's mail
server, then type 'ETRN foobar.com', and it'll dump all your email to
the IP address of your static configuration.

However, this won't work for roving users.



Nate
> 
> On Tue, 2 Oct 2001, Daniel O'Connor wrote:
> 
> > 
> > On 01-Oct-2001 Lyndon Nerenberg 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 is a shame, as it can still be a useful tool in certain
> > >  situations.
> > 
> > I think a more 'modern' solution is POP or IMAP over SSH, you can also feed
> > SMTP over an SSH tunnel too (This is what I use).
> > 
> > ---
> > Daniel O'Connor software and network engineer
> > for Genesis Software - http://www.gsoft.com.au
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> >   -- Andrew Tanenbaum
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> > 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

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

Re: HEADSUP!!!! KSE Milestone-2 COMMITTED

[Nate Williams]

Congratulations Julian, and thanks for all the hard work to you and the
rest of the folks!


Nate

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

Re: exec issue in tcsh?

[Nate Williams]

> >>> Wow.  Why not use xdm?  8)
> 
> >>Too lazy?
> 
> >Heh.  You just uncomment one line in /etc/ttys and HUP init.  It's not
> >compilicated.
> 
> Indeed.  However, there are some differences in startup of which to be
> aware (.xinitrc vs. .xsession).

I just hard-link the two files together. :)


Nate

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

Re: Copyright Contradiction in libalias

[Nate Williams]

> : On that released version, yes.  But, not on subsuquent versions.  I
> : still maintain my rights to do with the code as I please.
> 
> Then you are creating a new work, based on the public domain work that
> went before it.

I think we're splitting hairs here.  Ultimately, the exact same behavior
occurs no matter whose interpretation is correct.

Say I (Nate) create a work.  Let's go through the interpretation I've
heard, and see what happens, and then the interpretation others have
said, and see what happens.

Version 0.90 of the software has no copyright whatsoever, and I release
it to a couple of friends.

However, I spoke with a lawyer, and he tells me I'd better stick a
copyright on the front of my software, 'just in case'.  However, the
code is no different from V0.9, so I release version 0.98, which has the
following header on all the source code.
V0.98 Copyright 2001 Nate, All Rights reserved.

At some point in time, I deem the code worthy of release, and I create
Version 1.0, whose *only* difference from V0.98 is the copyright line
has changed.  This I give to some of the people who helped sponsor my
work, and I want them to do anything they want with it.
 V1.0 FooBletch - This software is placed in the public domain, 8/2001

At the same time, I create Version 1.1, whose *only* difference from
0.98 is the copyright line(s).  This I release on the Net.
 V1.0 FooBletch - Copyright 2001 Nate

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 [ yadda, yadda, yadda ]

You get the picture.

As I've been told, this is completely legal.  This means that a person
who receives V0.9 and 0.98 can't do much with my software, as they
essentially are the same thing.  V0.98 is just more explicit about it.

The folks who get V1.0 can do *anything* they want with it (can they
legally claim authorship?), including release it on the net if they
like, and even copyright it.

We all know what rights the folks who get V1.1 have.

At this point, everything is legal, because V1.1 is either a derivation
of V1.0 or V0.98, and as the author I'm free to do whatever I want with
my code, including putting it into the public domain.

So, that's my explanation.  Using Warner's (and others) explanation, the
following is what happens.

V0.9 and V0.98 are the same.

V1.0 is released into the public domain.

I (who have no additional rights) take 1.0, Copyright it, and release it
as V1.1.  

Ultimately, the same result as in my interpretation, as far as rights go
to all released copies of the software.

However, as I understand from the lawyers (not that I trust them much),
even the simple fact of modifying the files to change the copyright to
put it into the PD implies a 'derivative work', so therefore I still
have copyright status on the pre-PD version, and can do whatever I like
with it.  All prior unreleased versions are copyrighted, with or without
copyright statements.

Note, I understand that by releasing V1.0 into the public domain, I have
given up *ALL* my rights for the *exact* copy of the software released
into the public domain*.

But, I have not (necessarily) given up all my rights for any prior or
potentially subsequent derivations of said software, simple because I
still have rights on the prior copies and can derive future copies from
the past copies.

*phew*

Does that makes sense?  The only way to lose my rights completely is to
assign them to another entity (such as your employer), which most folks
do when they sign their employment agreement.

I think we're picking nits here, and ultimately it makes no difference
in the end results that are released.




Nate

> : > | As the original author, you never lose your rights to the software,
> : > | unless you assign your rights away to another entity, who knows has the
> : > 
> : > Or you abandon those rights by releasing it into the Public Domain.
> : 
> : See above.
> 
> But Andrew is right here.  You lose your rights to it when you
> abandoned your copyright to place it in the public domain.  Public
> Domain is a specific, legal term with legal consequences.  It means
> you have no rights whatsoever to the work and others can do whatever
> they like with the work.,
> 
> : > | Back to the original question, Charles Mott is the original author of
> : > | said code, and he can release his software under any license he so
> : > | pleases.  If someone has a copy of his software released under the PD
> : > | license, they are free to do with it as they please.  However, he can
> : > | *also* release a version under the BSD license (which he has), and that
> : > | version is now being distributed by FreeBSD.  This is all completely
> : > | free and legal, because Charles is within his legal rights to do so.
> : > 
> : > The Public Domain is not a license, it is an abandonment of copyright.
> : 
> : That's not how I understand it to be, from s

Re: Copyright Contradiction in libalias

[Nate Williams]

> | > If you ever claimed to hold the copyright to software that has been
> | > released into the public domain, you would be commiting fraud.
> | 
> | Not if I'm the author of the software.
> | 
> | I can release my software under as many licenses as I'd like, including
> | putting it into the public domain.
> 
> Once it's in the Public Domain you have abandoned your claim to copyright.

On that released version, yes.  But, not on subsuquent versions.  I
still maintain my rights to do with the code as I please.

> | As the original author, you never lose your rights to the software,
> | unless you assign your rights away to another entity, who knows has the
> 
> Or you abandon those rights by releasing it into the Public Domain.

See above.

> | Back to the original question, Charles Mott is the original author of
> | said code, and he can release his software under any license he so
> | pleases.  If someone has a copy of his software released under the PD
> | license, they are free to do with it as they please.  However, he can
> | *also* release a version under the BSD license (which he has), and that
> | version is now being distributed by FreeBSD.  This is all completely
> | free and legal, because Charles is within his legal rights to do so.
> 
> The Public Domain is not a license, it is an abandonment of copyright.

That's not how I understand it to be, from speaking with lawyers on it.

> If you find a piece of code, without a license attached, then copyright
> law prevents you from copying, modifying or redistributing that code
> (or book, or music) without written permission.

I believe this is part of the Berne Convention, no?  (And, it's not
necessarily agreed upon by *all* countries in the world, hence the
reason why certain companies explicity deny you to download software in
certain countries.  I believe Libya is one...)

> The GPL was born because Stallman got burnt by releasing a version of
> emacs (I think) into the Public Domain.

I don't believe it was PD code.  However, RMS never explicitly listed
the rights the users had, and another company took the software,
modified it, and started selling it as commercial software.  RMS still
had the rights on his original software, but he couldn't 'go back' and
take away the rights he had granted in his initial release, so he
couldn't stop the company from making money on 'his work'.

> I A company started selling it,
> and RMS had no claim to any of the monies, nor could he stop them from
> selling a binary only version of it (or selling it at all), nor could he
> force them to acknowledge it was written by him.

Actually, if I remember correctly, the company did acknowledge that he
wrote it, but that didn't help his cause.  (I actually got a catalog
from the company in question, but I can't remember the name offhand).

He was free to re-use the same software, and release it under a
different license for use in EMACS.  (I believe that EMACS still
contains some of the original LISP macros he initially developed, but
they are now under the GPL license.)



Nate

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

Re: Copyright Contradiction in libalias

[Nate Williams]

> If you ever claimed to hold the copyright to software that has been
> released into the public domain, you would be commiting fraud.

Not if I'm the author of the software.

I can release my software under as many licenses as I'd like, including
putting it into the public domain.

However, I can't retroactively take away the rights of anyone who has
gotten my 'public domain' software.

That is all.  I can release the exact same code under a zillion
different licenses, but once it's released, the people who have gotten
it can do whatever the license they received it under with the software,
and if that means 'public domain', that means they can do just about
anything with it.

However, *I* (as the original author) can release the software to
someone else, and if they aren't aware of the other (potentially more
liberally licensed) versions, they can be perfectly happy with the
software I've given them.

As the original author, you never lose your rights to the software,
unless you assign your rights away to another entity, who knows has the
same rights as you normally have.  That means they can release it under
multiple licenses, 

This is why folks can release software under both the GPL and BSD
licenses, and folks who work for the government must release it as PD,
and afterward someone takes that software and modifies it again, and the
modified version is licensed another way.

> If I have the only existing copy of some forgotten work by
> Shakespeare, I could sell it however I want under any terms I chose
> (licensing), but I cannot claim the copyright and be protected by
> copyright law above and beyond what I put in my license. If someone
> else finds a copy of it, I'm screwed.

Again, you aren't the author, or you have not been assigned the rights
by the original author (or whomever owned the copyright at the time).
However, most authors still have their original rights to do whatever
they please with their software, regardless of how they've released
their software in the past.

Back to the original question, Charles Mott is the original author of
said code, and he can release his software under any license he so
pleases.  If someone has a copy of his software released under the PD
license, they are free to do with it as they please.  However, he can
*also* release a version under the BSD license (which he has), and that
version is now being distributed by FreeBSD.  This is all completely
free and legal, because Charles is within his legal rights to do so.




Nate

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

Re: bash in /usr/local/bin?

[Nate Williams]

> I said I'd drop it, but apparently there are people that don't
> understand the dinosaur mentality of certain organizations such as
> DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC.

> If it's not in the base setup, on a production box, you can't use it.

*Huh*  This policy must have been implemented in the last 12 months,
since the last big contract my previous company did with the USMC, we
had a couple dozen Sun workstations, and I had all sorts of
'non-standard' software installed on it, including most of the GNU
utilities, gzip, etc  Prior to this contract, we did similar work
for the Army and there were few restrictions to the software we wrote
for them.

> Everything must be kept in it's ORIGINAL install location,

It's wherever the installation tools installed them into.  In the case
of the Solaris boxes, I think the stuff was all in /usr/local/bin, which
suprised me because I was used to 'optional' software going in
/opt/*/bin due to the packaging details that most pre-packaged 3rd party
software I've gotten for Solaris boxes.

> otherwise you MUST justify it and ask DISA/DECC for a waiver, which in
> itself, is a pain in the ass, and in many cases, not likely to happen
> due to dinosaur mentality.

Again, as a former USMC/DOD contracter, this was *certainly* not the
case.

> FreeBSD is getting military contracts now.

FreeBSD has been used in military contracts for *years* now.  Maybe it
wasn't as high-profile as the TrustedBSD work, but it's been in use by
the Government for quite a long time (and in a state where the people
involved had direct knowledge that FreeBSD was being used).

> I'm sure there are equally restrictive environments for computers and
> operating systems in *EVERY* country, but I speak from my personal
> experience with the dinosaurs at DOD.  At DOD, *EVERY* copy of FreeBSD
> will be subject to what I am saying.  In the Sun environment in which
> I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have
> been able to use it.  That's how backwards they are.

Again, my suspicion is that you're dealing with some very weird folks at
your installation.  My experience was quite different, and involved some
machines that were running hardened versions of Solaris on secret
networks, although I was never allowed to use those machines once they
were installed there. :) :)

Things aren't as bad as you're experience might suggest




Nate

ps. Amazingly enough, the software we had to integrate with (being used
by both branches) was *riddled* with remote exploit and DoS bugs, but
unfortunately they could not be fixed and still stay 'compliant'.  The
protocol was set in stone (gotta stay compatible), and some of the DoS
bugs were due to the incredibly stupid protocol being used.

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

Re: bash in /usr/local/bin?

[Nate Williams]

> > # Bash has a license which precludes its inclusion as part
> > # of the base system.
> > 
> > [Not that I favor more shells on the root file system, but anyway:]
> > What about gcc and grep? Does the license differ or are these not regarded
> > being part of the base system?
> 
> We would get rid of them if we could.  We keep their source
> code in a ghetto, since we can't.  Any company wanting to get
> rid of all GPL'ed and other restrictively licensed code in a
> FreeBSD based binary distribution can simply dike the ghetto
> out of the build tree, and build a still usable system binary
> from it, with no restrictively licensed code.
> 
> Changing grep and tar was an incredibly bad decision.  It has
> the distinction that the old, free code is there in the Attic,
> and can be recovered, if need be.

Umm, Terry.  There was no 'free' tar.  Back in the 386BSD days, when we
were looking for a free tar, I contacted Andy Tanenbaum (of Minix) and
got permission to use it, since we didn't have one.  However, it was
voted down as being 'too simple', so we opted for the GNU one.

There isn't a BSD or public domain version of tar anywhere to be found,
unless you consider 'pax' running in tar emulation mode acceptable.  (I
certainly don't.)

The same story exists with grep.


Nate

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

Re: lockup after resume

[Nate Williams]

> > One surprising observation: If I disable APM in /boot/device.hints, my
> > machine suspends and resumes JUST FINE.  The BIOS alone seems to be
> > able to suspend and awake the hardware behind FreeBSD's back.  The
> > system only hangs if FreeBSD is involved in the process.
> 
> Hmm, I might try that.
> 
> BTW, last time I asked Warner about this his reply was (I paraphrase)
> "it's not supposed to work, and if it ever worked for you it was out
> of sheer luck", which I find surprising.

Me too, since it used to work on that same hardware.  (A ThinkPad 600
was what I did the original suspend/resume work on during the FreeBSD
2.2 days.)




Nate

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

Re: ipfw: several equal rules under same number bug

[Nate Williams]

> How it can be possible? ipfw -a l:
> 
> 07001   401680 deny tcp from any to any 7006
> 070010   0 deny tcp from any to any 7006
> 070010   0 deny tcp from any to any 7006
> 
> I use equal "ipfw add" several times from the script, but the rule number
> was the same all times. I expect that rule is replaced, not added with
> same number several times.
> 
> Who is our ipfw guru at this moment?

This is the way it's been since day one in ipfw.  A rule is not an
atomic entity, so you can have every rule in your entire list with the
same number if you so desire.



Nate

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

Re: entropy bikesheds

[Nate Williams]

> Can we decide this, please - do we want secure startup (which will
> take some effort to achieve), or can we say "screw it" and start
> insecure like the old system?

Can we have both?  Ie; by default we are insecure until some point we
call an ioctl() that says 'no more, you must get real randomness now'.

So, that way we can do the stuff that doesn't require real randomness
(like mounting disks and such), and then once that's over with, the
system forces it into 'secure' mode, at which time it's up to the user
to supply some randomness for it.

If that happens, a user could decide comment out the 'real secure'
thing, and /dev/random would never block.

You can all laugh at me now. :)



Nate


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

Re: make release still broken...

[Nate Williams]

> > ===> rpcsvc
> > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h
> > rpcgen: cannot find any C preprocessor (cpp)
> > *** Error code 1
> 
> 
> Let me start a release.  This means rpcgen has been using
> /usr/libexec/cpp which is *only* for the compiler's use.  rpcgen should
> have been using /usr/bin/cpp all this time.

>From rpc_main.c

#ifdef __FreeBSD__
#define SUNOS_CPP "/usr/libexec/cpp"


Nate


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

Re: weird cvs update problem

[Nate Williams]

> > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c
> > > > U crypto/kerberosIV/appl/bsd/osfc2.c
> > > > U crypto/kerberosIV/appl/bsd/pathnames.h_
> > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c
> > > > cvs update: warning: unrecognized response ` If there are any IP options on 
>`sock', die.' from cvs server
> > > > cvs update: warning: unrecognized response ` */' from cvs server
> > [...]
> > 
> > It sounds like maybe the rcmd_util.c,v RCS file is corrupted on the
> > CVS server.  Just a guess.  I haven't seen the problem here.
> 
> Don't think so.. this happens rather randomly for random files
> (i.e., more than one).  The same file will update correctly on the
> second try (but then it barfs on another one).
> 
> It doesn't seem to happen for patched files, only for files that
> are downloaded whole.. ie, if you blow away an entire directory
> and then download it again.

Just a question.  Are you using any sort of transport mechanism (besides
rsh) in the middle?  I had problems like this when using F-Secure's
Windows client using compression, which blew up.  We switched the users
to SecureCRT and the problems went away.




Nate


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

Re: Fixing a.out compatibility

[Nate Williams]

> It seems feasable to generate a new binary on a recent or an old patched
> FreeBSD version.  The question is which is better.  I think the newer
> the better.  Otherwise, who is going to build the 2.2.8-stable box
> to make this one binary?  I've already built a binary on 4.2-release
> that works.

I've got a 2.2.8-stable box I am planning on building the ld.so binary
on.  I just have to find the time to do it.  (Been on vacation for
almost a week, and I've got 1600 FreeBSD emails to wade through
first...)


Nate


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

Re: /usr/local abuse

[Nate Williams]

> David hands Nate a freshly minted copy of BSD/OS 4.2, where he will see
> /usr/contrib/ burned on the CDROM (using an electron microscope of
> course :-)).
> 
> > Even Sun does this with it's 'OS vendor' tools.
> 
> Uhm.. not everything.  Many optional pieces from Sun installs in /opt.
> The SunPro compiler suite for instance is just one example.  One must add
> /opt/SUNWspro/bin to their path if they want to run it.

This must have changed recently, since at one point it installed at
least parts of itself in /usr/lib.



Nate


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

Re: /usr/local abuse

[Nate Williams]

> > : I know that as recent as 3=4 years ago, Purify installed itself by
> > : default in /usr/local, on SunOS and Solaris.  Lucid did this as well,
> > : although things start getting pretty fuzzy going back that far. :)
> > purify and the binary distributions of xemacs installed themselves
> > into /usr/local on Solaris in the 1992-1996 time frame.  As did *ALL*
> > of the software binaries we downloaded from the net.  Framemaker
> > installed in /usr/local as well in the SunOS 3.5/4.0 time frame.
> > Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame.
> 
> How much of that software did you get from the OS vendor?

Ahh, if we're limiting the discussio to 'OS vendor' software, then every
OS vendor I know installs its software in /usr/bin, and /usr/lib.  Even
Sun does this with it's 'OS vendor' tools.  Only 3rd party software
installed itself in /usr/local.

So, going with the 'OS vendor' argument, then all software should
install itself in /usr, and definitely not /usr/local.

Non-OS vendor software installs itself all over the place, but Solaris
*tries* to keep the software in /opt.

> > : > My claims about "history" and "tradition" are attempts to refute
> > : > Brandon's assertion that packages going into /usr/local has "years of
> > : > tradition behind it." Mostly, it's about what *packages* are, not what
> > : > /usr/local was used for.
> > : I disagree.
> > I do too.
> 
> Exactly what do you disagree with? That I'm arguing about what
> packages are? Or my assertion that packages installing in /usr/local
> doesn't have years of tradition behind it?


> 
> The former is clearly true. And I've never tried to claim that people
> haven't been installing third party software in /usr/local for years

And that third party software often installs itself in /usr/local by
default.

> (though some interpreted my comments about "locally maintained
> software" to exclude such). My claim is that the package system has
> grown into something other than "something to make installing third
> party software more convenient". It is pretty much a direct
> translation of some vendors practice of providing precompiled freeware
> into an OSS environment.

There is no standard for precompiled freeware distributed by OS vendors
that I'm aware of.  Packages I've downloaded from Sun put themselves
*all over* the place, including /opt/local, /usr/gnu, /opt/gnu, /opt,
and many other places.

I'm not even sure SCO's skunkware has a standard installation directory.

> Now, back to /usr/local and tradition - how many OS vendors provide
> software that installs in /usr/local.

SCO perhaps?  DEC did for awhile.  Sun may have even done it for some of
their 'development' tools on SunOS, so as to not wipe-out the default C
compiler in the system.



Nate


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

Re: Confusing error messages from shell image activation

[Nate Williams]

> > Fixing broken things is a good thing.  Your argument about 'moving it
> > from /usr/local to show how broken' is a good test procedure, but turning
> > it into policy is something completely different.
> > 
> > I think the 'tradition' of FreeBSD installing packages in /usr/local is
> > enough to leave things the way they are, especially since non-broken
> > packages allow you to install it somewhere else on *your* system.
> 
> You have to admit that the "prebuilt packages" argument is
> a pretty good one.  I don't used many myself (only cvsup, I
> think), but if it's true that the distribution CDs ship these
> pre-built programs, rather than the distfiles, then they should
> be built in such a way as to minimise the amount of "built-in
> policy".

I don't think anyone is agreeing.

> Building for /usr/pkg (which can be sym-linked to
> /usr/local) does seem to solve that problem, without having to
> invent a mechanism for tweaking compiled-in paths after the
> fact.

I don't see how building it for /usr/local or /usr/pkg by default
changes things.  If things are built for a default location, they'll be
broken no matter where they go.

> The default setup for locally built ports can stay exactly as it
> is.

I don't agree that we need to differentiate between 'pre-built' ports
and 'locally built' ports.  As a matter of fact, I think differentiating
only confuses things.

If the 'port' is broken w/regard to not using it's 'base', then it's
broken, no matter where it's installed to.  I think time would be better
spent fixing this brokeness rather than arguing where the default should
be. :)



Nate


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

Re: Confusing error messages from shell image activation

[Nate Williams]

> > I ran mostly DEC boxes until the early 90s, which had all software
> > installed in /usr/bin or /usr/local/bin.
> 
> Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early
> 90s, and don't remember anything being in /usr/local that I didn't
> drag of the net (or write myself) and install there, on either VAXen
> or MIPS boxes.

Hmm, trying to dig up memories of the software from that long ago.
Software that run a piece of chemistry hardware (a electronic
microscope?) sounds right, but I wouldn't bet my life on it.

> > > By your own admission, /usr/local wasn't used on v7. So the discussion
> > > should turn to when BSD started seeing prebuilt vendor packages to
> > > install in /usr/local.
> > Late '80s on DEC boxes running Ultrix (which one could argue is one of
> > the earliest commercial 'vendor' BSD unices).  I don't consider Solaris
> > a BSD unix, so it using /opt isn't a valid point, which makes the whole
> > concept of '/opt' for BSD packages a moot point. :)
> 
> I wish people would quite acting like moving packages out of
> /usr/local meant going to something like /opt. I don't think anyone in
> their right mind would suggest that.

'/opt', '/usr/pkg', '/whatever-you-want-to-call-it'.  You were the one
who claimed that Solaris was the first 'vendor' to provide packages, and
they used opt.

> > Probably the same time-frame for SunOS, although I didn't have
> > experience with it until the early 90's.  However, if necessary, I can
> > try and dig out installation docs for some software which ask to have
> > the stuff unpacked in /usr/local.
> 
> I'd certainly be interested in that.

It'd be Purify.

> Of course, as you yourself said, the argument about tradition is a
> sideline. 

Yep.

> The real issue is that ports/packages have one source, and
> things that may *not* have a mechanism to move them out of /usr/local
> (however badly broken) have another some of us want - quite
> legitimately - want to treat those two things differently, and
> packages using a directory name that has an established use makes that
> difficult.

Not true.  You can change the source to point to
'/usr/mike-likes-it-here', and it *should* work.  If it doesn't, then
it's borken. :)

Fixing broken things is a good thing.  Your argument about moving it
from /usr/local to show how broken is a good test procedure, but turning
it into policy is something completely different.

I think the 'tradition' of FreeBSD installing packages in /usr/local is
enough to leave things the way they are, especially since non-broken
packages allow you to install it somewhere else on *your* system.




Nate


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

Re: Confusing error messages from shell image activation

[Nate Williams]

> > > I'm aware that software was installing itself in /usr/local years
> > > before it was installing in /opt. On the other hand, vendor software
> > > was installing in /opt years before I ever saw it install in
> > > /usr/local.
> > Most vendor software I know pre-dates /opt, and installed itself in
> > /usr/local.  I'm with Warner on this one, installing in /usr/local
> > predates /opt by many years.  Before /opt, vendors always used
> > /usr/local, or worse they installed in /bin and /usr/bin.
> 
> Oh, I agree that installing things in /usr/local predates /opt by
> years. I'm curious as to what vendor provided software installed
> itself in /usr/local, though, as I've never seen any.

I know that as recent as 3=4 years ago, Purify installed itself by
default in /usr/local, on SunOS and Solaris.  Lucid did this as well,
although things start getting pretty fuzzy going back that far. :)

> > > Then again, your quoting of "packages" points up something else - I
> > > never saw prepackaged binaries for v6 or v7.
> > I did on SysIII.  As a matter of fact, the entire distribution was
> > bundled into separate packets (all of them installed in /usr). :(
> 
> SysIII was not something I ever worked with. I went from v7 to BSD
> until, and stayed pretty much BSD until I started working with Solaris
> in the early/mid 90s.

I ran mostly DEC boxes until the early 90s, which had all software
installed in /usr/bin or /usr/local/bin.

> > In any case, I think you're wasting your time trying to convince folks
> > here.  It appears to me that this is an argument going nowhere, and the
> > claims you're making of history and tradition are way off the mark, thus
> > making the arguments have much less weight.
> 
> I few this as consciousness-raising. That's an ongoing process.
> 
> My claims about "history" and "tradition" are attempts to refute
> Brandon's assertion that packages going into /usr/local has "years of
> tradition behind it." Mostly, it's about what *packages* are, not what
> /usr/local was used for.

I disagree.

> By your own admission, /usr/local wasn't used on v7. So the discussion
> should turn to when BSD started seeing prebuilt vendor packages to
> install in /usr/local.

Late '80s on DEC boxes running Ultrix (which one could argue is one of
the earliest commercial 'vendor' BSD unices).  I don't consider Solaris
a BSD unix, so it using /opt isn't a valid point, which makes the whole
concept of '/opt' for BSD packages a moot point. :)

Probably the same time-frame for SunOS, although I didn't have
experience with it until the early 90's.  However, if necessary, I can
try and dig out installation docs for some software which ask to have
the stuff unpacked in /usr/local.



Nate


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

Re: /usr/local abuse

[Nate Williams]

> Then again, your quoting of "packages" points up something else - I
> never saw prepackaged binaries for v6 or v7.

I did on SysIII.  As a matter of fact, the entire distribution was
bundled into separate packets (all of them installed in /usr). :(

> Or BSD, for that matter. I never encounterd a package system until
> Solaris.  That would make /opt a tradition as old as packages.

Not true.  There were package systems before 'Solaris', however
Solaris's package utility was much more powerful (annoying?) than
previous attempts.  One could argue that cpio is a 'package' utility,
but shar is probably the first 'package' utility that was used for
releases.

In any case, I think you're wasting your time trying to convince folks
here.  It appears to me that this is an argument going nowhere, and the
claims you're making of history and tradition are way off the mark, thus
making the arguments have much less weight.




Nate


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

Re: Confusing error messages from shell image activation

[Nate Williams]

> I'm aware that software was installing itself in /usr/local years
> before it was installing in /opt. On the other hand, vendor software
> was installing in /opt years before I ever saw it install in
> /usr/local.

Most vendor software I know pre-dates /opt, and installed itself in
/usr/local.  I'm with Warner on this one, installing in /usr/local
predates /opt by many years.  Before /opt, vendors always used
/usr/local, or worse they installed in /bin and /usr/bin.

> > : Rant second: FreeBSD *violates* years of traditions with it's
> > : treatment of /usr/local. /usr/local is for *local* things, not add-on
> > : software packages! Coopting /usr/local for non-local software creates
> > : needless complexity and confusion, which of course leads to needless
> > : pain.
> > Ummm, software packages have been make installing into /usr/local
> > since at least 1985 when I started building them.  no coopting has
> > been done.
> 
> If memory serves (and it may not at this remove), /usr/local/bin
> wasn't on my path until I started using VAXen, meaning there were few
> or no packages installing in /usr/local on v6 & v7 on the 11s.

On V7 (the earliest software I have), vendor software installed itself
in /usr/[bin|lib], which is IMO worse than /usr/local.


Nate


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

Re: Laptops and sc0/vt0 consoles

[Nate Williams]

> 
> Apologies upfront if anything I ask/say has already been covered, I'm
> somwhat limited in my resources at present.
> 
> In my past experience, FreeBSD hasn't agreed very well with IBM
> thinkpad laptops, unless you were using the vt0 console driver.

This is *VERY* old information.  When Pentium's were introduced
(755/560) series, it has no longer been a necessity.

The old 486 laptops need vt0, but anything newer works fine with sc0.

(I speak from experience, having had an IBM laptop for 7-8 years, and
being responsible for writing or integrating the code in FreeBSD to
support IBM Thinkpads.)

I'm also typing on a ThinkPad right now, which is my 'main' platform,
and it's doing fine with syscons, as have my previous 3 ThinkPads.



Nate


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

Re: Cardbus fixes

[Nate Williams]

> >I'll have to look up the CIS_PTR spec.  I'm not sure I like hardwiring
> >things like this.
> 
> Where did you get a copy of the pccard spec?  Do you have to order
> it from the pcmcia SIG?

Mike has my really old copy you can have (if you can get it from him),
and I think FreeBSD Inc. bought Warner a copy.

It's *HUGE*.



Nate


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

Re: ssh and scp fail connecting to a root account

[Nate Williams]

[ OpenSSH failure with particular malloc.conf flags ]

> Got it !
> 
> See version 1.6 of src/lib/libc/stdlib/setenv.c.  This took me all 
> night - Up for work in two hours !!! :-(

Good catch!


Nate


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

Re: make buildworld br0ken in libutil

[Nate Williams]

> > >> Alternatively the sentiment just rose why we couldn't just collapse the
> > >> crypt/hash functions of libcrypt into libc.
> > >>
> > >> It would make sense.
> > >
> > >It would make even make more sense to convince the other BSD to do the same
> > >(haven't checked recently what they do) and do the merge.
> > 
> > I very much agree.
> > 
> > Would it be sensible for the regular cypherpunks to discuss this with
> > the NetBSD and OpenBSD brothers?
> > 
> > Otherwise I would be willing to open this discussion on the appropriate
> > lists.
> 
> Is there any current policy on what libc is? It certainly isn't "libc"
> as required by C and hasn't been for almost ever but there needs to be
> some rational to its existence otherwise why not fold everything into
> libc and not bother with any other libraries!
> 
> A growing libc makes static binaries grow

NOT!  Static linking *only* brings in those symbols necessary for the
file.  It doesn't matter where those files are, they are only brought in
if necessary.

> and makes it more difficult to
> strip out unneeded functionality from a minimalist system install.

This is true.

> I'd been inclined to try and move things the other way and strip stuff
> out of libc into separate libraries but that's obviously not in vogue
> at the moment.

For what it's worth, I'm in agreement.  The 'kitchen sink' approach,
although easy tends to make stuff hard to maintain, since you end up
with namespace collisions, and you may end up with something you are not
aware of that conflicts with routines you are using inside your program.

(Think of the recent weak symbol discussion where the library is not
using the correct 'global' symbol for read as an example.)

> Why does crypt need to be in libc? Not even a significant fraction of
> applications need crypt?

Agreed.


Nate


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

Re: Ugly, slow shutdown

[Nate Williams]

> It's not just that, if you always have to cover your behind when
> doing tsleep you may wind up masking wakeup bugs.  Places like
> "vfs_bio.c" line 586 of 3182:
> 
>   bp->b_xflags |= BX_BKGRDWAIT;
>   tsleep(&bp->b_xflags, PRIBIO, "biord", 0);
>   if (bp->b_xflags & BX_BKGRDINPROG)
>   panic("bwrite: still writing");
>   }
> 
> If replaced by a while() _may_ obscure a buffercache bug.
> 
> Personally I'd like to be able to catch such bugs than let them go
> because the API (wakeups can happen at any time) prohibits this.

No in a fully threaded world.


Nate


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

Re: Anyone else seeing jumpy mice?

[Nate Williams]

> No, I don't mean rodents who've nibbled on chocolate-covered expresso
> beans, I mean PS/2 mice which fall victim to this new problem:
> 
> May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ).
> 
> I've seen it for the last few weeks and can only think that something
> must be stomping on the psm driver now (or the driver is missing
> interrupts for reasons of its own).  Anyone else seeing this?

Yep, it was related to having a newer mouse that wasn't supported quite
right under the psm code.  What I'm doing now is plugging in a different
mouse, and then switching mice *after* the probe succeeds which causes
the problem to go away.

I sent email to Kazu, but unfortunately I dropped the ball when he asked
for more feedback.


Nate

ps. It always seems to jump left and up...


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

Re: Motif is now Open Source 8)

[Nate Williams]

> > It requires two downloads to get a working JDK system.  No other OS
> > requires multiple packages to work.
> > 
> > People shouldn't have to compile Motif up just to get a non-source
> > version of the JDK to work.  Versioning problems that can be caused by
> > folks using different include files and/or X than what was used to build
> > the JDK.  Bugs that have slipped in due to changes in the Motif port
> > that negatively effect the JDK.
> > 
> > Shall I go on?
> 
> I'm curious... what happens when someone who has already installed Motif
> then tries to install JDK?

Nothing.  It should use the version inside the JDK, and it won't effect
the version outside the JDK.


Nate


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

Re: Motif is now Open Source 8)

[Nate Williams]

> >Unlike X (which rarely changes), I suspect the Motif stuff to change
> >alot.
> 
> I'm unclear on what gyrations you are expecting from a mature API
> codified in an IEEE standard.  As long as you're using the Motif
> standard interface in your code you should have nothing to worry about.

Ahh, but I'm not expecting the API to change, but I'm expecting the
internals to change.  For example, Sun changed Motif in between JDK1.1
and JDK1.2 because of bugs in it.  Also, Motif doesn't compile under
FreeBSD cleanly right now, and I expect it to change as it supports
internationalization and such.


Nate


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

Re: Motif is now Open Source 8)

[Nate Williams]

> > > If this Open Motif can be distributed as a port or package for FreeBSD
> > > itself (and it seems to me that it can), then what hassle is that for
> > > JDK on FreeBSD?
> >
> >It requires two downloads to get a working JDK system.  No other OS
> >requires multiple packages to work.
> 
> As long as package-dependencies are handled automatically, I do not
> see this as a problem.
> 
> >People shouldn't have to compile Motif up just to get a non-source
> >version of the JDK to work.  Versioning problems that can be caused by
> >folks using different include files and/or X than what was used to build
> >the JDK.  Bugs that have slipped in due to changes in the Motif port
> >that negatively effect the JDK.
> 
> Hmm.  You're saying that if I already have X installed, and if I already
> have Open Motif installed, then if JDK uses these already-working packages
> it will have bugs, and thus it has to install it's own version of
> Motif?

No, I'm saying that OpenSource Motif *will* be going through lots of
gyrations in the future, and these gyrations may cause instabilities in
the JDK.

But, if the JDK uses the Motif version it was compiled against, it will
work 'consistently.

Unlike X (which rarely changes), I suspect the Motif stuff to change
alot.


Nate


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

Re: Motif is now Open Source 8)

[Nate Williams]

> > > I think that you no longer have to include Motif with the JDK.
> > > Just let the distribution of Motif come from freebsd.org , i.e.,
> > > a port or a package.
> >
> >Too much hassle IMO.  I'd *much* rather distribute it as part of the
> >package, and I'm looking into how feasible it would be to distribute
> >inside of the JDK.
> 
> If this Open Motif can be distributed as a port or package for FreeBSD
> itself (and it seems to me that it can), then what hassle is that for
> JDK on FreeBSD?

It requires two downloads to get a working JDK system.  No other OS
requires multiple packages to work.

People shouldn't have to compile Motif up just to get a non-source
version of the JDK to work.  Versioning problems that can be caused by
folks using different include files and/or X than what was used to build
the JDK.  Bugs that have slipped in due to changes in the Motif port
that negatively effect the JDK.

Shall I go on?



Nate


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

Re: Motif is now Open Source 8)

[Nate Williams]

> > I have a copy.  However, the license is 'interesting' enough to read
> > that I'm not sure it can be used inside the JDK distribution, so if
> > someone can give me an explanation that I can understand that I'm legal
> > to distribute the library as part of an application, please show me in
> > terms a mere engineer can understand.
> 
> I think that you no longer have to include Motif with the JDK.
> Just let the distribution of Motif come from freebsd.org , i.e.,
> a port or a package.

Too much hassle IMO.  I'd *much* rather distribute it as part of the
package, and I'm looking into how feasible it would be to distribute
inside of the JDK.


Nate


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

Re: Motif is now Open Source 8)

[Nate Williams]

> Check it out at:
> http://www.opengroup.org/openmotif/
> 
> "We want to support the momentum of Open Source operating systems such as
> Linux® and FreeBSD by developing an Open Motif® licence for use with 
> Open Source operating systems."
> 
> Also the OpenGroup is looking for sites to mirror their Motif 
> distribution 8)

I have a copy.  However, the license is 'interesting' enough to read
that I'm not sure it can be used inside the JDK distribution, so if
someone can give me an explanation that I can understand that I'm legal
to distribute the library as part of an application, please show me in
terms a mere engineer can understand.

Thanks!


Nate


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

Re: HEADS UP: loader and libstand caution required.

[Nate Williams]

> Please be sure that you build and install libstand before building
> a loader!  (or use buildworld, that should work)

Good job tracking this one down Peter


Nate

> 
> FICL is now active on the Alpha, and actually seems to work.  The Alpha
> problems have been solved - it was an alignment issue of the end of code.
> Adding/removing code would make it fault.
> 
> I am not sure if the x86 loader will be affected by a mismatch, but I would
> not like to bet on it.  Be safe and make sure it is not linked against
> a stale libstand. :-)
> 
> Cheers,
> -Peter
> 
> --- Forwarded Message
> 
> Date:Fri, 12 May 2000 15:45:16 -0700
> From:Peter Wemm <[EMAIL PROTECTED]>
> To:  [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: cvs commit: src/sys/boot/alpha/common Makefile.common
> 
> peter   2000/05/12 15:45:16 PDT
> 
>   Modified files:
> sys/boot/alpha/common Makefile.common 
>   Log:
>   Reactivate the FICL hooks to make it be compiled in, but also initialize
>   FICL.  bootforth is now live on the Alpha!
>   
>   **BEWARE** - you *MUST* build and install a current libstand or you will
>   most likely get zfree() panics at loader startup.
>   
>   We should now be able to set up the loader.conf stuff on the Alpha too.
>   
>   Revision  ChangesPath
>   1.7   +9 -9  src/sys/boot/alpha/common/Makefile.common
> 
> --- End of Forwarded Message
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


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

Re: db 1.85 --> 2.x or 3.x?

[Nate Williams]

> >  Sleepycats license is not FreeBSD compatible :-/
> 
>   I don't understand.  Reading 
> , it seems to me that FreeBSD 
> meets all the necessary requirements.  Can someone who understands 
> the details of the licensing issues either explain the situation to 
> me, or provide pointers to references that do?

Sure, I built a commercial application on FreeBSD.  It looked up
usernames (which use DB routines).  Therefore, according to the
licensing scheme, I must now give away the entire source code to my
commercial application.

Second issue.  I use FreeBSD in an embedded system.  In order to not
*have* to distribute source code to my application, it's in my best
interest to strip out any GNU and similar code from the system before I
'ship' it.  (Which allows me to ship binaries to make the distribution
of my product easier).  However, I'm not using the newer DB routines, so
I must now provide source code to *everything*, and pointing to the
FreeBSD site is not adequate, because there are no time limitations, and
FreeBSD might yank the distribution on their site before a customer
stops using my hardware.

Is that easier?



Nate


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

Re: Archive pruning

[Nate Williams]

> > No-one needs to grab a repository, unless they're looking at history.
> > Just use CVSup to grab the latest bits, no need to grab the entire
> > history.
> 
> I find it virtually impossible to work with anything but the most stable 
> without the recent part of the repository because I often have to "unbreak" 
> something that was recently committed or is otherwise unfinished in order to 
> get a working system.

I consider you a very small minority.  A user who is not a developer,
but who could be a developer.  The amount of work it would take to
support your needs is way too much work, and it would only benefit <
1-2% of the user base.  Does this mean we don't care about all our
users?  Of course not, but when the same amount of time/effort can
positively effect > 50% of the user base, then it makes more sense to
spend the time more wisely.

> > Users have the choice to take it all, since trying to build a 'pruned
> > repository' is alot of work (due to the way CVS does it's thing), 
> 
> Actually, it isn't. it can be automated rather easily based on parsing the 
> CVS tags and using RCS primitives.

Actually, it can't be.  You can get about 90% of the way automatically,
and the remaining 10% requires human intervention (due to the way Attics
and tags are used).  Really it can't.  (Tried it in a previous project,
we gave up and ended up building a new repository).




Nate


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

Re: asm_pci.h,v Holy cow!

[Nate Williams]

> > If that's the _only_ point, then Garrett Wollman's idea should work
> > perfectly.  Stick the files under CVS
> 
> No, that was not my proposal.  I want to keep them out of CVS
> entirely.  CVS is Not Good at handling binary files (even if you never
> change them).  That's why I'd like them in a separate hierarchy.

Actually, CVS1.10 is *MUCH* better at handling binary files, although
you must be sure to set them up as binary files.

It works cross-platform and such, but if the file is not added as a
binary file, it really gets nasty. ;(

(Plus all of the size bloating issues, but that's a seperate issue IMO).


Nate


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

Re: Archive pruning

[Nate Williams]

> > I'd like to add that it can be particularly important when legal
> > questions arise. 
> 
> You confuse the argument for SOME complete repositories with
> the necessity that ALL (or at each most) repositories be so extensive.

No-one needs to grab a repository, unless they're looking at history.
Just use CVSup to grab the latest bits, no need to grab the entire
history.

Users have the choice to take it all, since trying to build a 'pruned
repository' is alot of work (due to the way CVS does it's thing), so the
all/nothing solution we have now should be good enough for 90% of the
users, which is a pretty good solution considering the volunteer
organization.


Nate


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

Re: Archive pruning

[Nate Williams]

> On Mon, 24 Apr 2000, Nate Williams wrote:
> > I'm violently opposed to removing it completely.  The only thing I
> > wouldn't be violently opposed to would be removing 'Attic' files (truly
> > unused file), and having them stored away somewhere in the tree for
> > archival purposes.
> 
> You realize that its possible to setup your local repo to drop these
> right?  (Attic files that is.)

Sure, but many of the Attic files in the tree are actually files that
are on an older branch that I'm currently using.  I don't want to spend
the time to figure out which files are 'unused' and whiche files are
'used but unused'. ;)

(Once CVS removes a file and sticks it in the Attic, it *never* is
removed from the Attic, even if it's added back into active status
again.)



Nate


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

Re: Archive pruning

[Nate Williams]

> I want to bring up a suggestion.  I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history more than 3 (or maybe 2, maybe 4) years old.

I'm violently opposed to removing it completely.  The only thing I
wouldn't be violently opposed to would be removing 'Attic' files (truly
unused file), and having them stored away somewhere in the tree for
archival purposes.

As far as removing old revisions from files, I'm even more violently
opposed to this.

> This could
> be done without too much pain, I think, in a script.  The purpose is to
> put some kind of cap on growth of the FreeBSD source archive.  While folks
> do sometimes go hunting for hugely old materials in the tree, I normally
> couldn't care less (when browsing) about history that old.

I quite often browse the source code in the tree, in particular I look
through the network code at how it's been modified over the years.

Also, I often-times go through the history.

> Do we really need 5 year old history?

Need?  As far as needs go, we don't need anything but the most recent
versions.  This is how Linux was developed for years, and it's a
nightmare.

The revisions take up very little space, and anyone capable and willing
to look through the history shouldn't mind having to see the history of
the file.  Heck, that's one of the big upsides to using source-code
control.


Nate


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

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Nate Williams]

> >Core should consider reverting the special rules that were originally
> >created with the expectation of major breakage in 5.x back to 
> >the set of rules we had for 3.x and 4.x. 
> 
> I have no idea what special rules you are talking about for 4.x/5.x.
> 
> 4.x-stable is a -stable tree and shall be treated as such.

I was under the impression that 4.x hasn't been designated as the stable
branch (yet).  That will happen when 4.1 is released, but until that
happens 3.x is still considered the -stable release.


Nate


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

Re: FreeBSD Build status

[Nate Williams]

> : > : Are you compiling with optimization turned on?  I believe mem* are
> : > : inlined if optimization is enabled.
> : > 
> : > Don't think so.  Both build -O.
> : 
> : Poul's build may not have optimization turned on, since it's controlled
> : by /etc/make.conf.
> 
> It isn't something specific to Poul's system.  I've recreated it here
> as well.  I've also tracked it down to the -fno-builtin that is in
> LINT, but not in GENERIC.  Now, to think about what to do about it...

I thought that the use of mem* and friends violated KNF.


Nate


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

Re: FreeBSD Build status

[Nate Williams]

> : Are you compiling with optimization turned on?  I believe mem* are
> : inlined if optimization is enabled.
> 
> Don't think so.  Both build -O.

Poul's build may not have optimization turned on, since it's controlled
by /etc/make.conf.



Nate


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

Re: FreeBSD Build status

[Nate Williams]

> >: awi.o(.text+0x3b4): undefined reference to `memcmp'
> >: awi.o(.text+0x3cf): undefined reference to `memset'
> >
> >What I want to know is why I don't get these with the GENERIC + awi
> >config file I have :-(

Are you compiling with optimization turned on?  I believe mem* are
inlined if optimization is enabled.


Nate


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

Re: Problems with MAKEDEV.

[Nate Williams]

> > >That's always struck me a bit odd... I thought 'MAKEDEV std' made
> > >the generic set of devices and that 'MAKEDEV all' should make... well..
> > >_ALL_. *shrug*
> > 
> > What do you define as `all'?  Say I have a big FTP server with 8 wide
> > SCSI controllers, each with 15 disks - that's da0..da119.  I might
> > have a big shell (or similar) server that needs a few thousand PTYs.
> > I could have all sorts of other wierd hardware.  "MAKEDEV all" has to
> > draw the line somewhere.
> 
> Sure.  What's the point of having both std and all, though?  How much does
> it hurt to have a few extra device files kicking around?  

You can easily run out of inodes on the roof partition.


Nate


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

Re: signal mask from jmp_buf

[Nate Williams]

> > What is the proper way for obtaining the signal mask from
> > within the jmp_buf struct on 4.x or -current?  Previously
> > with the JDK port for < 3.x we did something like this:
> > 
> > signalMask = jmpbuf[0]._sjb[6];
> > 
> > This no longer works now that we support >32 signals.  Is
> > there a better, more portable way that will work for all
> > versions of FreeBSD?
> > 
> > Thanks.
> 
> Hmm, OK, I'll bite.  
> 
> One of the things I've been looking at is getting rid of the
> sigprocmask() calls within setjmp/longjmp for libc_r (basically
> just switching to use _setjmp/_longjmp instead, since the
> threads library already knows what the signal mask of each
> thread is).  

Note, the JDK doesn't use the threads library, and instead uses it's own
thread library that is optimized for the JDK, so a solution that is
specific to libc_r won't necessarily help the JDK, although it may help
others.

> If we supported {get,set}context, I'd say use those instead
> of setjmp/longjmp since the signal mask is in ucp->uc_sigmask.
> I do have working {get,set,make,swap}context implemented as
> library routines for i386 (and also _getcontext,_setcontext
> which don't get/set the signal masks), and am working on the
> alpha bits (could use some help here).
> 
> I am unfamiliar with the JDK port.  Does it use FreeBSD native
> threads?

Nope, see above.  If/when FreeBSD gets 'real' kernel threads, it would
be worthwhile to move it to using them, but until that team my suspicion
is the optimzed 'threads' library that is part of the JDK probably is an
easier solution for the JDK.  However, Steve may have a different
opinion. :)




Nate


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

Re: Is there spinlocks/semaphores available for drivers?

[Nate Williams]

> :And would there still be areas of the kernel that disable multiple
> :interrupts, perhaps CAM or the network stack for instance?  What do
> :all the splbio and splnet calls translate into in this new scheme?
> :
> 
> The entire design of the kernel is currently predicated on the spl*()
> mechanism.  We obviously can't rip it out in a day.  I'm guessing it 
> will probably take two years ... or never if we can eek out sufficient
> performance with it still in place.

It is my (probably naive) understanding that BSDi has done a bunch of
work in this area, and that we should be able to leverage alot of their
work.  Having never seen it, I (bogusly?) assume they aren't using
spl*() anymore, given that they now have kernel threads.

Does anyone know more?



Nate


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

Re: Is there spinlocks/semaphores available for drivers?

[Nate Williams]

> :> :> *not* preempted except when being interrupted, so there are no
> :> :> 'priorities', per say.  Or, rather, the relative priority is strictly
> :> :> that the interrupt takes priority over supervisor code except when
> :> :> disabled by said supervisor code.
> :> :
> :> :But locks with owners wouldn't have to disable interrupts (given that
> :> :we have interrupt threads).  What about shared interrupts?  You could
> :> :still field and process the interrupt as long as it was for a different
> :> :device.
> :> :Dan Eischen
> :> 
> :> The word 'too bad' comes to mind re: shared interrupts.
> :
> :Too bad is not acceptable.  If we want to support multi-function
> :PCMCIA/CardBus cards, we *must* do shared interrupts, and multi-function
> :cards are becoming the standard, rather than the exception.
> :
> :Nate
> 
> First, each PCI slot has *two* assignable interrupts.
> 
> Second, CardBus cards are so slow that you would see absolutely no
> gain in performance whatsoever by being able to run concurrent interrupt
> threads for a single shared interrupt.

Huh?  CardBus cards are *not* slow.  PCMCIA cards are, but CardBus is
pretty dang fast.



Nate


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

Re: Is there spinlocks/semaphores available for drivers?

[Nate Williams]

> :> *not* preempted except when being interrupted, so there are no
> :> 'priorities', per say.  Or, rather, the relative priority is strictly
> :> that the interrupt takes priority over supervisor code except when
> :> disabled by said supervisor code.
> :
> :But locks with owners wouldn't have to disable interrupts (given that
> :we have interrupt threads).  What about shared interrupts?  You could
> :still field and process the interrupt as long as it was for a different
> :device.
> :Dan Eischen
> 
> The word 'too bad' comes to mind re: shared interrupts.

Too bad is not acceptable.  If we want to support multi-function
PCMCIA/CardBus cards, we *must* do shared interrupts, and multi-function
cards are becoming the standard, rather than the exception.



Nate


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

Re: problem with reboot on 5.0-current with VAIO

[Nate Williams]

> When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for
> the bufdaeon and the syncer to stop. Then the screen goes blank
> and the system completely hangs. Unplugging the battery and power
> is the only way to gte it booting again. It used to work fine with a 
> 4.0-current of some 3 weeks ago but a 5.0-current from today gives the above
> result. 
> Does anyone have a clue?

Is this use VM86?  The Thinkpads have this problem when the amount of
memory that FreeBSD expects is larger than what actually exists, due to
memory sizing issues.  VM86 is supposed to fix this, although I've not
run 5.0 to check it...




Nate


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

Re: NTP4 manual pages committed

[Nate Williams]

> Those of you who whined about the absence of manual pages in the NTP4
> package recently imported into the base system, please check your commit
> mail. 

Thanks Sheldon!


Nate


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

RE: load spike strangeness

[Nate Williams]

[ Moved to chat ]

> [Multiple irrelevant mailing-lists snipped.]
> 
> < said:
> 
> > Since when does an E-mail address require a "realname"?
> 
> As Sherlock Holmes once said: ``It is always unpleasant dealing with
> an alias.''
> 
> >plonk<

Boo... Hisss


Nate

;) ;) ;) ;) ;) ;) ;) ;) ;) ;)


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

Re: ipfw optimizations

[Nate Williams]

> > One of the things I would do to optimize ipfw is:
> > - instead of keeping one list with all the rules, split the list (the
> >   internal one) by interface and by direction (one list for ed1 incoming,
> >   one list for ed1 outgoing, etc.).
> 
> one skipto rule is enough to switch between two rulesets depending
> on direction, so this is not really worthwhile.
> I agree that having a `switch' type of rule for selecting interfaces
> would be a reasonable gain of efficiency (but then again.. how 
> many interfaces is one using!)

It doesn't matter, it has to do the lookup on a per-interface basis.  On
my firewall box, I have 11 interfaces.

Two ethernet, one loopback, 4 slip, and 4 tunnel.

I could easily see a speedup from using per-interface lists.


Nate


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

Re: ** HEADS UP ** chown&chgrp moved again

[Nate Williams]

> This week, I have added chown-like functionality to mknod(8) and restored
> chown & chgrp back to their previous locations.   MAKEDEV has been
> updated to use the new functionality of mknod(8).

Thanks for doing this David!


Nate


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

Re: PCCARD vs GENERIC

[Nate Williams]

> : So, my only comment is that if you believe that the code is stable
> : enough to not negatively effect desktop systems, and not too much bloat,
> : then have at it.  Note, enabling PCCARD functionality w/out APM will be
> : a losing situation for many laptops, and adding APM functionality for
> : desktops may be a losing situation.
> 
> The apm driver has been in GENERIC and PCCARD for a long time.

I know. ;)

revision 1.67
date: 1996/04/22 19:40:24;  author: nate;  state: Exp;  lines: +7 -1
- add apm to the GENERIC kernel (disabled by default), and add some comments
  regarding apm to LINT
..

> They are both have the "disabled" keyword so that the user can enable
> them in userconfig.  Also, apm on desktops makes more sense now than
> it used to, as many of the mobos now support it fairly well...

Except that it appears to break timekeeping on desktop machines.

Again, without APM, PCCARD support may give the impression as being
non-functional, since people will close the lids on the boxes and it
won't work correctly. :(


Nate


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

Re: PCCARD vs GENERIC

[Nate Williams]

> PCCARD used to exist separate from GENERIC due to the zp and ze
> drivers not being compatible with pccard's pcic driver.  These drivers
> were removed from the system not too long ago by phk.

The reason I added PCCARD to the system was because in the old code, I
didn't trust the PCCARD functionality to not negatively effect the
normal code.  Rather than potentially destabilize the desktop systems, I
kept the PCCARD kernel seperate.

The other reason is for the installation, but that's now a non-issue I
believe in -current, because one can use the standard install for both
desktop/laptop systems.

So, my only comment is that if you believe that the code is stable
enough to not negatively effect desktop systems, and not too much bloat,
then have at it.  Note, enabling PCCARD functionality w/out APM will be
a losing situation for many laptops, and adding APM functionality for
desktops may be a losing situation.



Nate


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

Re: HEADSUP: ntp4 to replace xntpd

[Nate Williams]

> >> Between the two of us Dave Mills and I have managed to get the
> >> "nanokernel" to act sensibly in the domain inside +/- 1usec which
> >> the old one didn't.  (See http://gps.freebsd.dk for what kind of
> >> performance this can result in, given appropriate hardware).
> >
> >You may not know the answer to this, but it's worth a shot.  Wht kind of
> >accuracy can we expect using 'cheap' off-the-shelf GPS receivers?
> 
> I think there are several classes of GPS receivers:
> 
> "What is a PPS signal ?"
> 
>   Typically handheld/boat naviation stuff.  The NMEA or other
>   serial timecodes are at best in the 1msec class.

Again, for me this is acceptable.  It would be nice to have it better
than this, but the kernel's of all the OS's I'm using have at best 1ms
precision for all of the applications being used (FS timestamps,
application program timestamps, etc...).

> "VP Marketing to VP engineering:  Everybody else has a PPS signal
> make sure our product has one too at no extra cost or schedule changes."
> 
>   You don't want to know.  As bad as 1msec have been seen,
>   jitter as bad as 200nsec.
> 
> "Straight PPS"
> 
>   Derived from the internal clock, typically in the "a few usec"
>   class.
> 
> "Position hold PPS"
> 
>   State of the art 1 band GPS does a stddev of about 35nsec.  The
>   Motorola Oncore UT+ is considered the leader of the pack I think,
>   other vendors have similar devices.
> 
> "Postion hold PPS + OCXO"
> 
>   OEM products doing basically what the HP 58503A does.
>   We're into cesium like (or better!) quality here.
> 
> I have *not* heard some rumours about carrier phase tracking low cost
> receivers, and I was *not* told that they can practically uwiggle
> the S/A when in position hold mode and I was *not* told to expect them
> on the market in 1H2000 :-)

As I mentioned to Warner, is there any way to know how good a particular
model of a GPS receiver is?


Nate


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

Re: HEADSUP: ntp4 to replace xntpd

[Nate Williams]

> : Cool.  I was under the impression that the cheap NMEA signals only gave
> : 2-5sec accuracy given the 2400 baud speed issues.
> 
> If you have a PPS signal, then you can get fairly close even if the
> inforation about the PPS signal comes in at 2400 baud.

Hmm, how do I find out how good it is?


Nate


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

Re: HEADSUP: ntp4 to replace xntpd

[Nate Williams]

> : > : You may not know the answer to this, but it's worth a shot.  Wht kind of
> : > : accuracy can we expect using 'cheap' off-the-shelf GPS receivers?
> : > 
> : > We're getting, with ntp4 on a 3.x kernel, about +- 4uSec with a cheap
> : > gps receiver + atomic clock on a i486 class machine.
> : 
> : I've got the cheap gps receiver (Garmin 12XL), but what do you mean by
> : an 'atomic clock'?  Should the GPS receiver's NMEA messages be adequate
> : enough to do the job?  However, all I need is ms accuracy, so anything
> : below 500us is good enough for me.
> 
> We have a cesium clock, which is generally called atomic clock, that
> we use for various things in our system.  If the GPS gives out a PPS
> signal for the NMEA, then you can likely hit 1mS w/o any problems at
> all.

Cool.  I was under the impression that the cheap NMEA signals only gave
2-5sec accuracy given the 2400 baud speed issues.

> Don't know a thing about the Garmin 12XL to know for sure about
> how it operates.

It just a standard 'cheap' GPS.


Nate


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

Re: Serious server-side NFS problem

[Nate Williams]

> : If people do a "settimeofday" we change the boot time since the
> : amount of time we've been up *IS* known for sure, whereas the boottime
> : is only an estimate.
> 
> There is one problem with this.  The amount of uptime isn't the same
> as the amount of time since the machine booted.  How can this happen?
> When a laptop suspends, it doesn't update the update while it is
> asleep, nor does it update the uptime by the amount of time that has
> been slept.

FWIW, we had code in the tree (just before the timeout_ch changes) that
did update all of the timeouts to 'fire' when the laptop was resumed.

This caused a 'thundering herd' problem at resume, but I don't see any
way around it...  However, it was lost when we changed to the different
timeout code.




Nate


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

Re: HEADSUP: ntp4 to replace xntpd

[Nate Williams]

> : You may not know the answer to this, but it's worth a shot.  Wht kind of
> : accuracy can we expect using 'cheap' off-the-shelf GPS receivers?
> 
> We're getting, with ntp4 on a 3.x kernel, about +- 4uSec with a cheap
> gps receiver + atomic clock on a i486 class machine.

I've got the cheap gps receiver (Garmin 12XL), but what do you mean by
an 'atomic clock'?  Should the GPS receiver's NMEA messages be adequate
enough to do the job?  However, all I need is ms accuracy, so anything
below 500us is good enough for me.

> The clock
> doesn't want to sync more closely than that, likely due to the large
> jitter in the 8254 timing device, so the atomic clock is a bit of a
> waste for this part of our application (there are others it is needed
> for).  With a pentium class machine and w/o the atomic clock
> "backing", I'd say you could easily get into the sub-micro second
> range.

I've got a 486, although running the antenna to an outside window might
get exciting. :)


Nate


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

Re: HEADSUP: ntp4 to replace xntpd

[Nate Williams]

> Between the two of us Dave Mills and I have managed to get the
> "nanokernel" to act sensibly in the domain inside +/- 1usec which
> the old one didn't.  (See http://gps.freebsd.dk for what kind of
> performance this can result in, given appropriate hardware).

You may not know the answer to this, but it's worth a shot.  Wht kind of
accuracy can we expect using 'cheap' off-the-shelf GPS receivers?


Nate


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

Re: Serious server-side NFS problem

[Nate Williams]

> In message <[EMAIL PROTECTED]>, Kevin Day writes:
> 
> >Ack, I was using this very same thing for several devices in an isolated
> >peer-to-peer network to decide who the 'master' was. (Whoever had been up
> >longest knew more about the state of the network) Having this change could
> >cause weirdness for me too... I assumed (without checking *thwap*) that
> >boottime was a constant.
> >
> >Perhaps a 'real_boottime' or 'unadjusted_boottime' that gets copied after
> >'boottime' gets initialized so that others can use it, not just NFS? :)
> 
> no, I think that is a bad idea.  In your case you want to use the
> "uptime" which *is* a measure of how long the system has been
> running.

Uptime is also a constantly changing number.  Forgive me for my
ignorance, but why does bootime constantly change?  I would have thought
it would be a constant?  I've got software that also uses this to
determine when a new copy of it exists (although I do keep a local cache
of the value in case my software crashes, since it can recover from a
crash, but not a reboot).

I would think that boottime would be constant, since you didn't keep
booting at a different time...



Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

>>> If half as much energy was spent adding the missing bits of
>>> functionality to the new systems as people have been spending
>>> complaining it then we'd be there ages ago.
>> 
>> Not true.  It doesn't take a disk expert to complain about a policy,
>> but it takes one to fix bugs/add features to the existing driver. :)
>> :) :)
> 
> That's ignoring the fact that it takes less energy to become enough of a 
> "disk expert" to do something useful than it takes to engage in the sort 
> of protracted whining that we're seeing.

That's simply not true.  It's taken me less than 5 minutes total to
respond to these silly emails, and it'd take me at least a week to get
familiar enough with the code to do anything useful, and another 3-4
weeks to get it past the maintainer's filters (validly so), because my
one week of understanding would be missing alot of lessons learned that
I'm not aware of.

However, it appears to be the mindset of the developers that the
problems that people complain about are either trivially easy to solve
that it's expected that unless they have a solution to it, they're
stupid.

Or, the problem is so hard that they want people not to complain unless
they have a solution for it, since expecting *THE DEVELOPERS* to solve
such a protracted and complex set of problems is ludicrous.  You must be
an idiot to not understand this, or a complete boob for expecting a
member of a volunteer project to spend his free time working on it.

In other words, and opion shared that is contrary to the developers
implies stupidity on the part of the user.  It's a no-win situation for
everyone involved.




Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> If half as much energy was spent adding the missing bits of functionality
> to the new systems as people have been spending complaining it then we'd be
> there ages ago.

Not true.  It doesn't take a disk expert to complain about a policy, but
it takes one to fix bugs/add features to the existing driver. :) :) :)



Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> >> >> In a few days time the wd driver will be retired from FreeBSDs
> >> >> i386 architecture.
> >> >
> >> >Given that the ATA driver just went active a few minutes ago, I think a
> >> >period of shakeout time would be called for.  I think that time should
> >> >be longer than a few days, and should be in 4.0, and then retired in
> >> >4.1.
> >> 
> >> The ata driver has been available for you and other to test for a long
> >> time. 
> >
> >And your point is?  I'm a user, not a developer.  If I wanted to be a
> >developer, I'd have written my own device driver.  I want to *USE*
> >FreeBSD, not develop it.
> 
> Then don't run -current.

I don't, but I will be running 4.0, which won't have a WD driver.


Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> What is a killer is if a large number of people on popular hardware can't
> even boot, *at all*, in no, way, shape or form.  Only that.  The only way
> to find that out for sure before 4.0 is to push the issue *now*.

I disagree, but I'm not making the decision.


Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> >> In a few days time the wd driver will be retired from FreeBSDs
> >> i386 architecture.
> >
> >Given that the ATA driver just went active a few minutes ago, I think a
> >period of shakeout time would be called for.  I think that time should
> >be longer than a few days, and should be in 4.0, and then retired in
> >4.1.
> 
> The ata driver has been available for you and other to test for a long
> time. 

And your point is?  I'm a user, not a developer.  If I wanted to be a
developer, I'd have written my own device driver.  I want to *USE*
FreeBSD, not develop it.

It's been considered 'alpha quality' until a couple of days ago.  I
wouldn't install beta software on any of my systems, and now you're
telling me that in order to use FreeBSD, I have to become a beta-tester,
since it may/may not work on my systems.

> 4.0-REL is still some time away, so if you are quick you can still
> give it a good shakeout and have any bugs you find fixed before
> 4.0-RELEASE.

So, again, who are our customers here?  A bunch of developers who enjoy
beta-testing other people's code, or people who want to *USE* FreeBSD?


Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> In message <[EMAIL PROTECTED]>, Nate Williams writes:
> >> What we need here is a commitment to these new initiatives, not a lot of 
> >> fence-sitting and clutching our knitting to our chests.
> >
> >If all our users were developers I would agree.  But *most* of our users
> >are not developers.
> 
> -CURRENT should have very few users who are not developers in some
> capacity.

Sure, but in a couple of weeks, -current will be 4.0-Release, which is
not -current anymore.

> >Good question.  What are we trying to achieve here?  I thought it was to
> >provide the best OS that is usable to the largest number of users?
> 
> And this requires us to move away the old cruft so we force the
> people on the bleeding edge to test the new stuff.

Force people is what I'm having problems with.  *Most* people will
install 4.0, and give it a good shakeout.  The rest of the people are
choosing to stick with the old driver for their reasons, and you're (in
effect) telling them that you know better than they do what their needs
are.

And, you're 'forcing' them to either cod or have their systems not work
as well as they used to do.  From my experience, this is unacceptable if
we're in the business of providing a product/service to our users.

So, I ask again, what exactly are we trying to accomplish here?


> All in all, it sounds to me like a lot of people are presenting
> a stance which can be summarized as:
> 
>   "why should *I* have to be guinea-pig for the ata driver
>   in -current make somebody else test it first."

Right, there are people *WILLING* to test it.

> To which the answer is:  If you decide to run -current you have
> tacitly agreed to be a guinea-pig for FreeBSD developers, so
> shut up and test.

I'm with Warner.  If the ATA driver went golden 2-3 months ago, then I'd
say go for it.  But not 2-3 days ago.  You're only telling your
user-base that they are less important than you are.  (Although, this
may be what you believe, so who am I to tell you otherwise).





Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> What we need here is a commitment to these new initiatives, not a lot of 
> fence-sitting and clutching our knitting to our chests.

If all our users were developers I would agree.  But *most* of our users
are not developers.

> Again, I say, think of what we're trying to achieve here.

Good question.  What are we trying to achieve here?  I thought it was to
provide the best OS that is usable to the largest number of users?



Nate


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

Re: HEADSUP: wd driver will be retired!

[Nate Williams]

> In a few days time the wd driver will be retired from FreeBSDs
> i386 architecture.

Given that the ATA driver just went active a few minutes ago, I think a
period of shakeout time would be called for.  I think that time should
be longer than a few days, and should be in 4.0, and then retired in
4.1.


Nate


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

Re: HEADS UP, bind update shortly...

[Nate Williams]

> I'm about to import bind 8.2.2.p5 into src/contrib/bind and fix up the
> broken parts of the tree as I go.  I will disable the named (and associated
> tools) build for the duration.  If you want to do some make worlds or
> releases in the next 8 hours or so, do a cvsup pronto!

Thanks Peter!


Nate


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

Re: need patch review - NFS fixes for IP binding

[Nate Williams]

> Instead, I have adopted and cleaned up the kernel portions of the patch
> and modified nfsd to allow the binding ip/host to be specified on the
> command line.  Thus nfsd can be run bound to a specific IP address.

This sounds like a great solution, thanks Matt!


Nate


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

Re: GENERIC build broken

[Nate Williams]

> > > I think most if not all the ethernet cards I or my customers
> > > have bought over the last year have sported mighty fine netboot
> > > capabilities.
> > 
> > FWIW, few of the cards I've bought over the years sport netboot.  And,
> > netboot is an impossibility in 'embedded' systems that use things like
> > PCMCIA/CARDBUS, which are becoming common-place for embedded routers and
> > such.
> 
> Argh!  More FUD!  Network booting is not an impossibility in an 
> embedded product using PCCARD or CARDBUS.

Ok, please explain how I add a netboot prom to my 3C589 card?

> > Netboot (IMO) is an unacceptable solution to many folks.  It seems that
> > 'progress' in this case means removing alot of existing functionality
> > that is used by a number of folks.
> > 
> > (CDROM root, BOOTP, etc...)
> 
> More FUD!  CDROM root devices still work fine.

Then you do a very poor job of writing commit logs.

+++
msmith  1999/11/01 15:51:01 PST

  Modified files:
sys/kern vfs_conf.c 
...
  Log:
  This is a complete rewrite of vfs_conf.c, which changes the way the
root
  filesystem is discovered. 

  In addition, support for CDROM root
  devices has been removed; it was a nasty hack and didn't work.
+++

Note the last sentence.  Does that say that support for CDROM root
devices has been removed?  I thought it did.

> The automated search 
> stuff was broken, and it's gone because it was in the way.  There will 
> be a new automated search process that will work properly.

I thought the general idea was that *until* something better came along,
you left things the way they were (ie; not removing them).  That's
certainly the message that's been communicated in the past.

> BOOTP in 
> the kernel will go _when_there_is_an_acceptable_alternative_.

You've already stated *THERE IS AN ACCEPTABLE ALTERNATIVE*, and it's
PXE.  (I can use all caps instead of underscores to make a point too :)

> Yes, progress means losing the crap.

One man's crap is another man's diamond...

> How much more like a shark would you look like if you didn't lose your
> baby teeth?

There ya go, Mike.  Let's degenerate this dicussion into name calling
and putdowns, cause that'll make you feel better, won't it?


Nate


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

Re: GENERIC build broken

[Nate Williams]

> I think most if not all the ethernet cards I or my customers
> have bought over the last year have sported mighty fine netboot
> capabilities.

FWIW, few of the cards I've bought over the years sport netboot.  And,
netboot is an impossibility in 'embedded' systems that use things like
PCMCIA/CARDBUS, which are becoming common-place for embedded routers and
such.

Netboot (IMO) is an unacceptable solution to many folks.  It seems that
'progress' in this case means removing alot of existing functionality
that is used by a number of folks.

(CDROM root, BOOTP, etc...)




Nate


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

Re: People getting automatically unsub'ed from -arch

[Nate Williams]

> > "Accidental" removals from the lists are so common that I give up.  I no
> > longer even try to get back on them -- it's been happening for _years_ now,
> > and I have made multiple complaints about it, and if it's not a problem for
> > whoever runs the mailing lists, then I just don't care that much.
> 
>   only one comment.   i remove people from the lists whenever
> their email bounces.

How long do you wait to determine 'bounced' email?  I've bounced mail to
hotmail recently, and it wasn't hotmail accounts problem.  (No comments
from the peanut gallery, it's an easy way for our folks on the road to
get email simply.. :)

> the threshhold is approximately 30 messages in a
> 24 hour period. 

Or 5 minutes worth of emai on -hackers. :)

> mail may bounce due to DNS problems, mail box full,
> MTA misconfiguration.  i also remove people that send vacation
> messages to the list.  oh, and spammers.

How do you cause 'vacation' to not send messages to the list?  Doesn't
the stock 'vacation' program as shipped in FreeBSD send them to the
list?

>   i do NOT send the person mail to inform them that the are
> being removed from the mailing lists, because their email is bouncing.

Sometimes.:)

> > I have a hard enough time remembering which lists I subscribed to that I do
> > get traffic on to check every day to see which ones have removed me without
> > informing me.
> 
>   several people with recurring email delivery problems have
> written a script to monitor their subscriptions for them. 

Some of the people (who apparently have problems) didn't even know they
had problems

Even so, do you have a copy of said scripts?  Given that -arch and
-security are not allowed to use the 'which' command, do they simply
re-subscribe themselves on a weekly basis 'just in case'?

Inquiring minds would like to know...

Even a simple way of finding out (obviously not via email) *IF* I had
been subscribed would be great.  A 'unsubscribed' mailing list that I
could run 'which' on that would tell me which lists I'm no longer on,
however I can imagine that would be a lot of work.




Nate


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

Re: People getting automatically unsub'ed from -arch

[Nate Williams]

> [Mayhaps too many Cc:'s kept in order to reach relevant audience]

Thanks, sorry about the X-posting...

> On Sun, Oct 10, 1999 at 02:57:55PM -0600, Nate Williams wrote:
> > > I Can't believe this email only produced TWO responses!
> > > I would have thought that this wouldhav brought out the chainsaws!
> > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't
> > > work? (the only responders got it via 'core')
> > 
> > Interesting.  It appears that somehow I got 'unsubscribed' from arch.
> > Not sure why, but in May I was subscribed, but I'm no longer subscribed.
> > 
> > Did everyone get unsubscribed when it went idle?
> 
> Not *everybody*, at least - my subscription has kept.  I do not know
> of any mass-unsubscription.

Hmm, weird.  I can see that the 'old' list of people was saved on hub as
'freebsd-arch.19990501', of which I'm a member.  However, I never
received the email Simon Shapiro sent out in June that I just read, so I
know I was removed then.

I also note that freebsd-arch is the only 'list' that has a backup copy,
so *something* happened, and someone knew about it.  (I'm not implying
that it was intentional to remove people, or what, but *something*
happened and there was no mention of it...)



Nate


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

Re: People getting automatically unsub'ed from -arch

[Nate Williams]

> > > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't
> > > > work? (the only responders got it via 'core')
> > > 
> > > Interesting.  It appears that somehow I got 'unsubscribed' from arch.
> > > Not sure why, but in May I was subscribed, but I'm no longer subscribed.
> > > 
> > > Did everyone get unsubscribed when it went idle?
> > 
> > Not *everybody*, at least - my subscription has kept.  I do not know
> > of any mass-unsubscription.
> 
> Hmm, weird.  I can see that the 'old' list of people was saved on hub as
> 'freebsd-arch.19990501', of which I'm a member.  However, I never
> received the email Simon Shapiro sent out in June that I just read, so I
> know I was removed then.

I note that David is no longer on the list ([EMAIL PROTECTED] was
'unsubscribed, either accidentally or intentionally).  Justin is gone,
and many other folks I would have considered to be folks interested that
were once subscribed...



Nate


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

Re: The eventual fate of BLOCK devices.

[Nate Williams]

> I Can't believe this email only produced TWO responses!
> I would have thought that this wouldhav brought out the chainsaws!
> Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't
> work? (the only responders got it via 'core')

Interesting.  It appears that somehow I got 'unsubscribed' from arch.
Not sure why, but in May I was subscribed, but I'm no longer subscribed.

Did everyone get unsubscribed when it went idle?

(I'm not commenting on the content as I haven't done enough research to
agree/disagree with anything yet.)


Nate


> 
> julian
> 
> On Sat, 9 Oct 1999, Bruce Evans wrote:
> 
> > > PHK has been moving steadily in this direction to remove as many 
> > > dependencies within the kernel on block devices as possible.
> > > The question is, When did the decision to do so become official?
> > 
> > Never.
> > 
> > > I don't believe it has been a stated official decision yet and so in order
> > > to put some clarity into the air over this I'd like to launch a PURELY
> > > TECHNICAL discussion on the topic.
> > > 
> > > Here are some starters.
> > > 
> > >  1/ block device writes have to be synchrnous or the user doesn't get
> > > write errors.
> > 
> > Block devices should be implmented properly or the user doesn't get write
> > errors.
> > 
> > A proper implementation is quite close.  Write errors should be reported
> > on last-close and on fsync().  They already are as far as I can see, modulo
> > the bugs that (in -current) VOP_FSYNC() = ffs_fsync() sometimes hangs
> > instead of returning a write error and vinvalbuf() sometimes panics instead
> > of returning a write error.  The bugs are different and worse in RELENG_3.
> > The bugs are different and more benign in RELENG_2_2 (write errors are
> > ignored).  Note that the bugs have very little to do with specfs.  All
> > specfs can reasonably do is kill the endless retries at a suitable time,
> > probably after calling vinvalbuf() in last-close.
> > 
> > >  1A/ if they are not synchronous, errors need to be coped with in some
> > > other manner.
> > 
> > Normal error handling suffices, modulo bugs.
> > 
> > >  2/ People with old UNIX experience expect to be able to do unalligned
> > > transfers on block devices. 
> > >  3/ DEVFS can cope just fine with block and char devices
> > > (I include this because DEVFS has been used as an argument for
> > > removing them)
> > 
> > Correct.
> > 
> > >  4/ Most of the block buffering code in the kernel will remain due to 
> > > the VM and VFS systems.
> > 
> > Well, if the Nth rewrite of vm wants to drop support for buffers in vfs,
> > then use of buffers for block devices shouldn't stop it.
> > 
> > >  5/ New users don't tend to understand the rather strange distinctions
> > > between BLK and CHR devices. Some people consider having both POLA and
> > 
> > This is an argument for removing character (disk) devices, since most
> > new users will be from Linux where block (disk) devices were the only
> > ones available until recently.  Block devices have always worked better
> > in Linux.  E.g., media change is detected for floppies, and buffers
> > remain valid across last-close, until media change.  The latter behaviour
> > can be not what is wanted (extra ioctls are needed to discard the buffers),
> > but it is often useful.
> > 
> > > others consider having only one POLA. Linux had til just recently,
> > > only BLK disk devices. They just aded CHR disk devices but I don't
> > > know if they created a whole second calss of device to do so. (I doubt it)
> > > 6/  It should be possible to make an overlay device (similar to the way
> > > ccd works), that supplies buffered characteristics to a disk. This may
> > > be a different minor number or a differnt major number.. but be a CHR
> > > type device.
> > 
> > This would involve needless duplicatication of half of the buffer cache
> > implementation (maybe the simple half) unless the buffer cache goes away.
> > 
> > Bruce
> > 
> > 
> 
> 
> 


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

Re: make install trick

[Nate Williams]

> In any case, you should not be doing lots of writes to root, so the
> lack of softupdates should not be a problem.

So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.

And, if you do lots of development, then you'll have the same problem on
/tmp as you did on / unless you waste a huge disk for /tmp. :(


Nate


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

Re: sigset_t: a summary

[Nate Williams]

> 1. Should the ucontext_t changes be backed out, or is this the
>way we would like to go? (but only it better :-)

We need something.  Rather than say 'something better', I'd need to see
what that better things is.  However, given Bruce's comments earlier, it
seems like we need to have ucontext_t to stay compatible.



Nate


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