Re: recent apm changes

[Nate Williams]

> plm> In contract, if I suspend in Linux of Windows, the computer shuts up
> plm> immediateley and is quiet. Only sometimes there is a (not too loud)
> plm> little fan (I think it is the CPU fan) running for a few more minutes.
> 
> I've read Linux code (v2.2.9) closely, noticed they put cli 
> before APM BIOS call and save & restore segment registers.

The CLI call is bogus.

I note a commit I *just* made:

revision 1.49.2.4
date: 1999/07/10 18:36:59;  author: nate;  state: Exp;  lines: +1 -2
- Remove un-necessary CLI statement from apm_int, which casues
  suspend/resume to fail on at least some IBM Thinkpads.
[ FWIW, the cli call is also missing from -current ]

Submitted by:   "Kenton A. Hoover" <[EMAIL PROTECTED]>


If the CLI is there, my box refuses to suspend.  Apparently it was
removed from linux a while back, and like many software projects that
don't have usable history, the bug is now being re-introduced into Linux
again. :(

As far as the segment registers, we do an explicit save of them already
when we switch into VM86 mode, so it should be necessary to save them
twice.

> I suspect these two (or only cli?) affect the suspending state.
> To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) 
> one by one?

I'd be interested to know if either of the patches did anything...




Nate


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

Re: recent apm changes

[Nate Williams]

> > As far as the segment registers, we do an explicit save of them already
> > when we switch into VM86 mode, so it should be necessary to save them
> > twice.
> 
> VM86 mode is only used to enable APM; after that we are using the 
> 32-bit protected mode interface.

Ahh...  In the old code, we used to explicitly push/pop all of the
registers.  Do we still do that?


Nate


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

Re: it's time...

[Nate Williams]

> : Correct, but the nature of the kernel probe/attach messages is to convey
> : information in a readable, consistent, useful manner.
> 
> Agreed.  However, what's magical about 80 columns?

What's magical is that almost every text console is limited to 80
columns (think serial console), as well as the standard default size for
terminal emulators is 80 columns.

  My editors go out
> to 180 sometimes.  The console can easily be placed into a mode where
> it is > 80.  This is especially true for the serial console where it
> might be connected to a 132 column printer.

Just because it *can* be connected to a 132 column printer doesn't mean
it *will* be connected.  Most printers that I use are 80 columns wide.
Heck, almost *every* printer I use is that wide, hence the whole 80
column thing.

The most common case for a console is an 80 column wide console (this is
the default for the virtual terminals, most printers, most text
terminals, etc..)

Changing it is silly, and non-standard.

> No!  At some point they should use a facility similar to solaris/sysv
> where they don't display, but do make it into the dmesg buffer...

On my Solaris box, they are displayed at boot time.



Nate


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

Re: it's time...

[Nate Williams]

> : The line wrapping stuff I brought back for the EISA bus stuff in -current
> : makes it easy to define the wrap point.  If some small number of people
> : want the ability to wrap at 132 or 40 or whatever, I don't think its
> : unreasonable to provide them the knob to tweak in the boot loader.
> 
> Despite what nate think about 80 columns, my PDA cannot display more
> than between 30-45 characters, depending on the font, so having a knob
> for that would be useful in the long term.

And you plan on booting FreeBSD on your PDA?

> It also would allow one to kick the VGA display into 132 columns in
> the boot loader and have more of a chance to get more of the boot
> process on the screen.  syscons already supports parts of this...

My firewall doesn't have a VGA display. :(

> There is no reason to hard code 80 into the kernel.  Otherwise one
> could argue why have stty columns at all :-).

stty columns is only effective *AFTER* you have a shell and the box has
booted.


Nate


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

Re: it's time...

[Nate Williams]

> : stty columns is only effective *AFTER* you have a shell and the box has
> : booted.
> 
> Yes I know that, but you seem to be arguing that all terminals have 80
> columns...  This is not the case, although many of them do.

Most of them do.  It is the 'least common denominator' that FreeBSD runs
into.  More than 132 columns is an exception, as well as less than 80
columns.

My point was not changing the boot message to more than 80 columns, like
you suggested.



Nate


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

Re: recent apm changes

[Nate Williams]

> APM Spec. v1.2 Appendix D - APM Driver Considerations -

FWIW, the wording here is almost the same as the previous
specifications.

> When an APM connection exists, the APM BIOS transitions into System
> Standby and System Suspend states only when directed to do so by a
> call from the APM Driver. The calls to change system states are
> invoked by the APM Driver only after the APM BIOS indicates that the
> state transition should be made, and the APM Driver has checked with
> all APM-aware applications to make sure that it is an appropriate time
> to change system states. However, there are three cases where the APM
> BIOS may make the system state transition itself. The first case is if
> the APM Driver does not pick up a posted Standby Request, Suspend
> Request or Critical Suspend Notification event within the 2 second
>~~~
> (one second plus one second grace period) time limit. The second is
> when the APM Driver, after picking up the event, does not respond to a
> Standby Request, Suspend Request or Critical Suspend Notification
> event with an appropriate Set Power State call within 5 seconds of
>
> receiving the event.

We should have no problems responding in this amount of time in FreeBSD,
since we don't (didn't used to?) have any code that should cause
significant delay in responding.

> The last situation is when the APM Driver has
> responded to an event with a Request Processing Set Power call and
> does not reply again within another 5 seconds.The CPU is power managed
> according to CPU Idle and CPU Busy calls made by the APM Driver to the
> APM BIOS.

I don't follow this.

> 
> 
> Last time, we didn't have `Last Request Processing Notification' to
> APM BIOS at all for the second case.

Huh?  I don't see any mention of 'last request processing notification'
anywhere above.  Also, I don't believe the APM driver responds with a
request processing call, since I don't see any reason to in FreeBSD,
especially with the number of buggy BIOS's out there.



Nate


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

Re: IBM ThinkPad 600E with cardbus EtherJet 10/100 :)

[Nate Williams]

> 1: any access to the serial port (/dev/cuaa0) locks the machine.

Weird.  I haven't tried accessing mine though, but I know there are lots
of weird setup issues that must be done to get the serial port to be
read correctly.

> 2: I cannot get the ethernet card to work.
>   2a: It is sort-a recognized by the system, It senses the insert and remove,
>   but it cannot get the CIS.  I remember reading somewhere that the CIS
>   on these cards is 'somewhere else' and you can tell pccardd where that is.
>   2b: I believe that this is in reality a tulip card.

Then it's not supported, since it would be a CardBus ethernet card.

> I am in no way opposed to beta software, and I will code as need be, I
> just need to know where things already are before I get my feet wet.

You need to get an old PCCARD ethernet card, since the 600E does work
in PCCARD emulation mode.

I absolutely *love* mine.



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: 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: 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: 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: SIO "lost interrupt" status in current?

[Nate Williams]

> I'm actually pretty sure it happens even without X11 live. This worries me!
> changing the modem serial speed down from 57600 through 33600 to 19200 made
> no difference.  This also worries me.

If the speed isn't being set down, then somehow interrupts are being
turned off for a very long time, possibly by another device driver, or
possibly you have bad hardware.


Nate


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

Re: SIO "lost interrupt" status in current?

[Nate Williams]

>   > I'm actually pretty sure it happens even without X11 live. This worries m
>  e!
>   > changing the modem serial speed down from 57600 through 33600 to 19200 ma
>  de
>   > no difference.  This also worries me.
>   
>   If the speed isn't being set down, then somehow interrupts are being
>   turned off for a very long time, possibly by another device driver, or
>   possibly you have bad hardware.
> 
> If interrupts were off, wouldn't I see other things like mice freezes or
> X-repaint problems?

Nope, because they are less sensitive to the timing then serial lines.

> I'd go with either of these actually. Any suggestions for debug methods?

Look through the mailing lists.  I'm sure Bruce had some debug ideas in
the past.



Nate


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

Re: followup to apm problems.

[Nate Williams]

> : And it seems there still are other devices which wake your PC up in
> : 2-3 mins time.
> : Hmmm, anyone has ideas?
> 
> I think we need to set the interrupt mask to 0 in the PIC.

I don't think makes any difference, since the APM Bios is in charge of
what happens at this point, and the BIOS is below the level of the OS.



Nate


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

Re: start xdm on a particular vty

[Nate Williams]

> There have been discussions about the xdm entry /etc/ttys does not guarantee
> the X server being started on the particular vty. So I wrote a shell script
> to explicitly tell xdm to start X server on a specific vty.

I *like* it.  I think you should share it with the XFree86 folks, and I
think this would be great to have in the base installation (after proper
testing of course...).

However, does this work with non-XFree86 X servers?  (Or, maybe you
can't test that...)


Nate


 It's been working
> great. I'd like to share it with you, maybe we could include it in the base
> system. Here's the script (I call it xdmstart), it's very simple,
> 
> #!/bin/sh
> case $1 in
> ttyv*)
>   vt=vt`expr $1 : 'ttyv\(.*\)' + 1`;;
> *)vt=;;
> esac
> exec /usr/X11R6/bin/xdm -nodaemon -server ":0 local /usr/X11R6/bin/X :0 $vt"
> 
> and in /etc/ttys replace the xdm line with
> ttyv3   "/usr/local/bin/xdmstart"  xterm   on  secure
> 
> There's one thing should be noted, the vtxx option isn't a standard X server
> option, but both XFree86 and Xig support it, so majority of the people should
> be covered.
> 
> -lq
> 
> 
> 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: start xdm on a particular vty

[Nate Williams]

>>> There have been discussions about the xdm entry /etc/ttys does not
>>> guarantee the X server being started on the particular vty. So I
>>> wrote a shell script to explicitly tell xdm to start X server on a
>>> specific vty.
>> 
>> I *like* it.  I think you should share it with the XFree86 folks, and
>> I think this would be great to have in the base installation (after
>> proper testing of course...).

> Do you know the appropriate channel to contact the XFree86 folks?

Try [EMAIL PROTECTED], who is supposedly the FreeBSD contact for XFree86.

> > However, does this work with non-XFree86 X servers?  (Or, maybe you
> > can't test that...)
> > 
> I've only tested it with XFree86. Xig's document indicates it also supports
> the vtxx option (but I am unable to test it). I don't know anything about
> servers from other vendors.

Great.  I'll see if I can try it out at home on my XIG server...


Nate


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

Re: start xdm on a particular vty

[Nate Williams]

> > Do you know the appropriate channel to contact the XFree86 folks? In the
> > mean while, I can take Sheldon's advice, submit it to our XFree86 port.
> 
> By the way, I've just thought of something you should consider. I think
> there's still a problem with xdm, where trying to change vty while it's
> starting up can lose you access to all your vtys.

This isn't a problem with xdm, but with syscons.  There were some
patches floating around that fixed this is a really kludgey way posted
or send-pr'd a while back that supposedly fixed this, but no-one
followed up on it (including myself...)



Nate


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

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

[Nate Williams]

> > I think that java is still broken by this.
> > 
..
> >> java
> > Segmentation fault (core dumped)
> >>
> 
> I've just committed the fix in "src/libexec/rtld-elf/rtld.h" revision
> 1.12.  The Java runtime was peeking into some of the dynamic linker's
> private data structures.  My recent changes added some new members
> which changed the layout of the structures.  I've moved the new
> members to the end to work around the problem.
> 
> This is really a JDK bug, but I understand they did it that way to
> work around limitations in the dynamic linker.  I'll try to help them
> find a less fragile way.

This is necessary because the JDK has no way of knowing if dladdr() and
other misc. functions exist at runtime, because it must run on *all*
versions of FreeBSD, and older versions of 3.* didn't have these
functions.

We can't maintain backward compatability 'cleanly' w/out knowing the
internals unfortunately.  That is, unless John can come up with a way
that we're not aware of. :) :) :) :)



Nate


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

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

[Nate Williams]

> > This is necessary because the JDK has no way of knowing if dladdr() and
> > other misc. functions exist at runtime, because it must run on *all*
> > versions of FreeBSD, and older versions of 3.* didn't have these
> > functions.
> > 
> > We can't maintain backward compatability 'cleanly' w/out knowing the
> > internals unfortunately.  That is, unless John can come up with a way
> > that we're not aware of. :) :) :) :)
> 
> I've been thinking about this.  I think I know a good way to find out
> at runtime whether dladdr is implemented, and also a safer way to roll
> your own version of dladdr to use when necessary.

Sounds just like what the doctor ordered...

> I have to do some
> Real Work at the moment, but I'll follow up with more details soon.
> (In other words: I have devised a clever and elegant proof of this
> theorem.  Unfortunately there is not room in the margin to write it
> down ... ;-)

Let me know. :)


Nate


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

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

[Nate Williams]

> OK, sorry for the delay.  Here's what I'd recommend for Java:

Thanks for the hints.  I've forwarded them onto the developer mailing
list, and will respond to you with any comments he has.



Nate


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

Re: ccd build failure

[Nate Williams]

> :[Insert semi-nasty message about how people should really be testing 
> :their changes before they commit, how it is a blatant disregard for
> :basic human rigths not to do so etc etc etc]
> 
...
> Insert nasty message about how people shouldn't post idiotic comments.

Play nice boys!  Remeber the first rule of committers. *grin*


Nate


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

Re: On hub.freebsd.org refusing to talk to dialups

[Nate Williams]

> > I agree.
> > 
> > > Your work also has a serious security concern if it allows this you to
> > > directly attatch to it's port 25.
> > 
> > No it doesn't, but you do bring up another good point why not to use the
> > ISP's mail server.  Security.  I don't want email to bounce on your box
> > and potentially give the ISP's postmaster information they shouldn't be
> > having.  (Including email about us switching ISP's because we hate their
> > email policy. :)
> 
> If your mail is sensitive use a proper transport, encrypt it.

All mail is senstive, it just that sometimes that the cost of encrypting
is more expensive than the cost of setting everyone up so they can
decrypt it.  In short, there is no 'portable' way of
encrypting/decrypting mail.

> > Yes, our ISP *could* sniff packets are read our email if they wanted,
> > but it would be a breach of contract for them to do so.
> 
> No, it would not.

*YES*, it would.  Don't tell me what my ISP can/can not do, because you
have no idea.

> > Basically, I think not allowing ISP's to allow the Dialup lines to
> > forward email as a good thing, but for them to limit was businesses do
> > with their IP traffic is simply too big brother'ish, no matter what
> > their contract states.
> 
> If _we_ don't start to do something about it, big brother _is_ going
> to do something about it.

Now you're going off the deep-end.  Big-brother has shown that they
simply don't *care* what happens, to the point that SPAM is still
legal to do in almost all cases, and people must opt-out of it.

> They also have great benifits by agreeing to our standard AUP, they
> have RBL filtering done, etc, etc, etc.  This is the _service_ part
> of ISP that every one else leaves out.

As I stated before, any decent ISP will take the time to help a client
setup services they desire, not do it for them.  Doing it for a customer
WHO WANTS TO DO IT THEMSELVES is the unix way.  We're doing it, because
you're too stupid/clueless to do it yourself, and we're not going to
give out the 'secret' information.

If the customer doesn't want to host it themselves, then by all means
have the ability to do it for them, and you can charge them for it
even. :)

But, just because you think you are an ISP doesn't make you any more
expert than people running their own businesses off it.



Nate


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

Re: On hub.freebsd.org refusing to talk to dialups

[Nate Williams]

> > would immediately unsubscribe to any isp that decided this was acceptable 
> > behavior on their part.

I agree.

> Your work also has a serious security concern if it allows this you to
> directly attatch to it's port 25.

No it doesn't, but you do bring up another good point why not to use the
ISP's mail server.  Security.  I don't want email to bounce on your box
and potentially give the ISP's postmaster information they shouldn't be
having.  (Including email about us switching ISP's because we hate their
email policy. :)

Yes, our ISP *could* sniff packets are read our email if they wanted,
but it would be a breach of contract for them to do so.

Basically, I think not allowing ISP's to allow the Dialup lines to
forward email as a good thing, but for them to limit was businesses do
with their IP traffic is simply too big brother'ish, no matter what
their contract states.

I'm as much at risk (or more) from spammers that abuse my mail host as
they are, so it behooves me to setup my mail machine (and network) to
'Do The Right Thing'.  Rather than ISP's blocking email, they should
instead be working with their customers to provide them with expertise
on how to setup a working/usable mail server.



Nate


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

Re: HEADS UP: sigset_t changes committed

[Nate Williams]

> I just finished committing the sigset_t changes I worked on for the last
> 5 weeks.

Thanks Marcel, this was great, and the commit messages were outstanding
(as well as humorous :).



Nate


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

Re: HEADS UP: sigset_t changes committed

[Nate Williams]

> Following up on my previous mail regarding the panic on the Alpha,
> I've been looking at the diff for the code in question, in
> "src/sys/nfs/nfs_socket.c":
> 
> @@ -1501,14 +1502,16 @@
> struct nfsreq *rep;
> register struct proc *p;
>  {
> +   sigset_t tmpset;
>  
> +   tmpset = p->p_siglist;
> +   SIGSETNAND(tmpset, p->p_sigmask);
> +   SIGSETNAND(tmpset, p->p_sigignore);
> if (rep && (rep->r_flags & R_SOFTTERM))
> return (EINTR);
> if (!(nmp->nm_flag & NFSMNT_INT))
> return (0);
> -   if (p && p->p_siglist &&
> -   (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> -   NFSINT_SIGMASK))
> +   if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> return (EINTR);
> return (0);
>  }
> 
> It looks like the old code was prepared for "p" to be NULL, but the
> new code assumes it is non-NULL.

Am I missing something?

 -   if (p && p->p_siglist &&
 -   (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
 -   NFSINT_SIGMASK))
 +   if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))

The 
if (p 

in both cases checks for an null p.  Or, am I missing something?



Nate


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

Re: HEADS UP: sigset_t changes committed

[Nate Williams]

> Nate Williams wrote:
> >> Following up on my previous mail regarding the panic on the Alpha,
> >> I've been looking at the diff for the code in question, in
> >> "src/sys/nfs/nfs_socket.c":
> >> 
> >> @@ -1501,14 +1502,16 @@
> >> struct nfsreq *rep;
> >> register struct proc *p;
> >>  {
> >> +   sigset_t tmpset;
> >>  
> >> +   tmpset = p->p_siglist;
> >> +   SIGSETNAND(tmpset, p->p_sigmask);
> >> +   SIGSETNAND(tmpset, p->p_sigignore);
> >> if (rep && (rep->r_flags & R_SOFTTERM))
> >> return (EINTR);
> >> if (!(nmp->nm_flag & NFSMNT_INT))
> >> return (0);
> >> -   if (p && p->p_siglist &&
> >> -   (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> >> -   NFSINT_SIGMASK))
> >> +   if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> >> return (EINTR);
> >> return (0);
> >>  }
> >> 
> >> It looks like the old code was prepared for "p" to be NULL, but the
> >> new code assumes it is non-NULL.
> > 
> > Am I missing something?
> > 
> >  -   if (p && p->p_siglist &&
> >  -   (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> >  -   NFSINT_SIGMASK))
> >  +   if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> > 
> > The 
> >   if (p 
> > 
> > in both cases checks for an null p.  Or, am I missing something?
> 
> You're missing the use of "p->p_siglist" that was added at the top
> of the function.

Whoops, thanks for pointing that out.

Just call me 'mole-eyed Nate'. *sigh*



Nate


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

Re: Now that sigcontext is gone ...

[Nate Williams]

> I'm trying to digest the recent signal changes and get a handle on
> what I need to do to make Modula-3 work.  There is code in the runtime
> currently which catches SIGBUS and uses the sigcontext's "sc_err"
> member to find out the faulting address.  That should be replaced
> by the siginfo_t's "si_addr" member.  But as far as I can tell from
> grepping the kernel sources, that functionality isn't implemented.
> 
> Is that right?  Any ideas regarding a work-around?

I'm also very interested in this, so if you could post this information
publically, it would be greatly appreciated



Nate


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

Re: new sigset_t and upgrading: a proposal

[Nate Williams]

> > Mainly historical bugs.  Includes are installed too early and they only
> > match the new syscalls.  Tools are built using the new includes, so they
> > need new libraries to be consistent.  Therefore the new libraries are
> > built before the new tools.  These bugs were implemented in FreeBSD-1 by
> > someone named rgrimes :-).
> 
> I'll eat the crow, yes, I did implement that.  It was the first step
> at even being able to ``make world''.  Had to start some place.  And
> technically the bug dates back to the patchkit, infact probably  a
> 1.x version of the 386BSD PatchKit.

Naw, 386BSD was never able to 'build itself' from scratch.  That was a
FreeBSD/rgrimes addition, bugs and all. :) :) :)


Nate


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

Re: HEADS UP: sigset_t changes committed

[Nate Williams]

> you don't under stand, we are NOT talking about upgrades, we are talking
> about how to make a buildable system on -stable... 

There are essentially the same problem.  In order to do an upgrade, you
have to be able to build on -stable. :)

> ===> libgcc
> echo '#include ' > config.h
> echo '#include ' >> config.h
> echo '#include "i386/xm-i386.h"' > tconfig.h
> echo '#include "i386/i386.h"' > tm.h
> echo '#include "i386/att.h"' >> tm.h
> echo '#include "i386/freebsd.h"' >> tm.h
> echo '#include "i386/perform.h"' >> tm.h
> cc -c -nostdinc -O -pipe -pipe -O -pipe -O 
>-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
> 
>-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc
> -I. -fexceptions -DIN_GCC 
>-I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o 
>_mulsi3.o 
>/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c
> cc1: Invalid option `-fexceptions'

This is unrelated to the signal code.  Why are you jumping on Marcel for
this?

In any case, I believe there is work in progress as well as interest in
making *something* work.  Let's all quit yelling at one another and
start working towards a solution, instead of pointing fingers and
screaming 'he broke it and won't fix it'. :)


Nate


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

Re: HEADS UP: sigset_t changes committed

[Nate Williams]

> P.S. It is really hard for me to not make personal attacks against you
> after all of the above and completely ignoring the rest of my message.

No, I didn't.  My statement was that your 'confrontational' style of
email wasn't making things any better.

Mellow it out, and instead of attacking first (thus putting folks on the
defense) and then providing content, skip the first step.

This is the same as you've done with the response to me, attack first
and ask questions later.  :(




Nate


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

Re: Now that sigcontext is gone ...

[Nate Williams]

> > Sigcontext will have to come back, since it is a standard BSD interface.
> 
> I think so too.  I bet there are several ports besides Modula-3 that
> use it.  Probably boehm-gc does.

The JDK does as well, at least for the green-threads stuff.



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

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: 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: 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: 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]

> > "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: 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: 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: Java segfaulting

[Nate Williams]

> I'm running -current as of 9:00 CDT October 30, and ever since I rebuilt, I
> have not been able to run any Java applications.  All of them exit with
> the following error output:

Running Java on -current is at best a hit-miss operation, simply because
we were forced to hard-code in some linker information into the JVM to
support FreeBSD 3.0-3.2.  This can cause problems in FreeBSD 4.*, since
often the linker changes.

This is not to say that it is due to those kinds of changes, but given
the number of *large* scale changes to the entire 4.0 system, I'm
suprised it works at all.

At this point, the only platforms that I expect the JDK to work are
2.2.*/3.*.



Nate


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

Re: gzip(1) hanging

[Nate Williams]

> I've got a -current box freshly CVSup'd and built from last
> night that is exhibiting some rather bizarre behavior.  I
> actually noticed the problem on my Alpha package building
> machine, but the same behavior exists on my i386 box.
> 
> To see what I'm seeing (or maybe not :) all you have to do
> is this:
> 
>   cd /usr/ports/graphics/jpeg
>   make extract

Martin C. made a change to 'sh' yesterday with regards to
file-descriptors that might have something to do with this...


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: 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: 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: 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 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]

> >> 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]

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

> 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]

>>> 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: 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: 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: 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: 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.
> 
> 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: 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]

> >> 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: 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: 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: 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: 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: 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]

> :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: 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: 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: 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: 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]

> : > : 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: 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: 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: 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'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: 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]

> > 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: 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: 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: 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: 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]

> > > 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]

> > > 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]

> >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]

> > 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: 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: 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: 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: 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: 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]

> > > 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]

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

> 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: 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: 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: 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: 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: 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: 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: 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: 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: 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