Hypocrites
What's going on here? markm 2003/02/02 01:01:30 PST Modified files: .access Log: See mail sent to [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Revision ChangesPath 1.364 +0 -1 CVSROOT/access Why is this being kept secret? My friend Matt Dillon got his commit bit removed once more. Why? Where's the so called FreeBSD openness? Hey Mark, you haven't even contributed 10 lines of code to the project, yet you disable Matt's access. You're a moron. Where's the public explanation for this? Or maybe it's just jealousy on your part? It's not Glass we are talking about, it's Matt Dillon. For Christ's sake, he's probably the best hacker in the whole team. Sincerely, Matthew Damon _ gifts, travel, e-cards, free e-mail, and more! .. http://www.egypt7000.com .. _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChip driver("fla").
David Yeske <[EMAIL PROTECTED]> writes: > I still use this. Users will not suddenly quit using hardware that > works, they will start using a different OS that works with it, or > they will be stuck trying to continue to support an old version of > FreeBSD because it works with it. Read the announcement again. FreeBSD 5.x will still have DoC support, which means you have at least two years to grow tired of it before we stop putting out 5.x releases. By that time you will hopefully have realised it is a dead-end technology and switched to something that works. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
Sergey Babkin <[EMAIL PROTECTED]> writes: > Also the GNU grep has a lot more options, the most interesting > of them being -r. Unfortunately, GNU grep's -r option is broken (it does not handle symnlinks correctly). Try textproc/freegrep from ports instead. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
Doug Barton <[EMAIL PROTECTED]> writes: > On Tue, 28 Jan 2003, Garance A Drosihn wrote: > > Well for one thing, if a given file has a lot of changes, then I > > would like mergemaster to skip over the initial one-line change > > that only tells me how some comment now has a new version-number > > in it. > This is an oft-requested feature, but I'm not sure how best to implement > it. Look up the -I option in the diff(1) man page. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to make .so to find symbol from other .so?
I have the following setup: Main executable loads module X, which in turn loads modules Y.so and Z.so (optionally, depending on the configuration). All loads are done with dlopen with flags RTLD_LAZY|RTLD_GLOBAL. Now, module Y needs to know address of some symbol from module Z in case Z.so is loaded. On linux and solaris, the code along these lines works: void *this_module = dlopen(NULL, RTLD_LAZY|RTLD_GLOBAL); return dlsym(this_module, symbol_name); However, on FreeBSD 3.4 and 4.0 it doesn't work - the dlsym returns NULL. The question is - how to make it work? I know that latest FreeBSD versions have dlsym(RTLD_DEFAULT, symbol_name), which is supposed to help. However, I need it to work on 3.4 and 4.0 too. What can be done about this? Is there any alternative way of doing this? The problem is that module Y doesn't also know the full path for Z.so, though it can know if it was loaded or not - thus I can not use dlopen with path name to go directly to Z.so. Any suggestions? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
That's very cool! Congratulations! NetBSD has a BSD sort, I understand it's based on the Minix version, so we are getting very near to cleaning all the utilities from the GPL. cheers, Pedro. --- "James P. Howard II" <[EMAIL PROTECTED]> ha scritto: > Dag-Erling Smorgrav said: > > Sergey Babkin <[EMAIL PROTECTED]> writes: > >> Also the GNU grep has a lot more options, the > most interesting > >> of them being -r. > > > > Unfortunately, GNU grep's -r option is broken (it > does not handle > > symnlinks correctly). Try textproc/freegrep from > ports instead. > > I have received patches over the past week that put > freegrep's speed > within striking distance of GNU. Sometime RSN I am > going to release an > update incorporating these patches. > > Jamie > > __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vfork / execve / accept lock
here is a sample code (vfork_execve.c) to demonstrate a locking problem. The code launch 3 threads : 1 signal 2 endless do nothing 3 a socket server (bind to 127.0.0.1:12345) The server accept 3 cmd: 1) close => close cnx 2) sleep => use vfork /execv to launch external "/bin/sleep 20" to reproduce the lock: launch ./vfork_execve connect to server: =>telnet 127.1 12345 type quickly sleep close =>telnet 127.1 12345 ->close the process telnet and vfork_execve is locked until the first 'sleep' cmd has return. I've no idea why the process locks; maybe an implementation trouble or a bug. Any suggestions are welcome. Best Regards. CC=gcc CFLAGS= -ansi -Wall -I/usr/local/ssl/include SPEC_INC_BSD= -DUNDER_BSD CCFLAGS_BSD= -g2 $(CFLAGS) $(SPEC_INC_BSD) LIB_THREAD_LINUX= -lpthread LIB_THREAD_BSD= -pthread LIBS_SOLARIS= -lsocket -lnsl LIB_LINUX= LIB_BSD= CCFLAGS=$(CCFLAGS) LIBS= $(LIB_THREAD_LINUX) $(LIB_BSD) OBJ= $(SRC:.c=.o) all: vfork_execve vfork_execve2 vfork_execve: vfork_execve.o $(CC) -o vfork_execve $(LIBS) vfork_execve.o vfork_execve.o: vfork_execve.c $(CC) $(CCFLAGS) -o $*.o -c $*.c vfork_execve2: vfork_execve2.o $(CC) -o vfork_execve2 $(LIBS) vfork_execve2.o vfork_execve2.o: vfork_execve2.c $(CC) $(CCFLAGS) -o $*.o -c $*.c clean: @rm -f *.o y.tab.c lex.yy.c <><>
Re: vfork / execve / accept lock
ok sorry, change on Makefile : CCFLAGS=$(CCFLAGS_BSD) LIBS= $(LIB_THREAD_BSD) $(LIB_BSD) Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Poll: Should Mark Murray be removed from core?
Gentlemen, cast your vote: 1) Mark Murray considered harmful 2) Nah, keep the person that has just removed Dillon's commit bit, yet isn't making any significant contribution to the project. You have until Feb 15 to vote. Poll result will be forwarded to core and a decision will be made. Thank you for making FreeBSD better. _ gifts, travel, e-cards, free e-mail, and more! .. http://www.egypt7000.com .. _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Request for info from SiS chipset owners
On 01-Feb-2003 Soeren Schmidt wrote: > > I'm currently in the midst of an ATA chipset support mega rewrite/update, > and the last item on the list is SiS support. > > That where _you_ come into the picture, I need a pciconf -l from your > SiS based system! > > Just reply to this message with the output from pciconf -l and you > have helped me sort out the myriads of SiS chipsets out there. This is from a -stable system but: chip0@pci0:0:0: class=0x06 card=0x chip=0x06451039 rev=0x01 hdr=0x00 pcib2@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00 ohci0@pci0:2:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 ohci1@pci0:2:3: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 atapci0@pci0:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 rl0@pci0:6:0: class=0x02 card=0x13011186 chip=0x13001186 rev=0x10 hdr=0x00 none0@pci0:9:0: class=0x040100 card=0x80641102 chip=0x00021102 rev=0x08 hdr=0x00 none1@pci0:9:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x08 hdr=0x00 none2@pci1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002 rev=0x00 hdr=0x00 -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vfork / execve / accept lock
rmkml wrote: > here is a sample code (vfork_execve.c) to demonstrate a locking problem. The short answer is that your code is wrong. The longer answer is that your code is assuming implementation details in vfork() which are undefined in threaded programs, according to the standard, and is assuming that the threads implementation is in the kernel, and assuming that the threads are created via a process similar to vfork(). Since the standard permits implementations to be in user space, and fork interaction is undefined, and signal delivery targeting is undefined, you should probably expect that any threaded program using signals or using fork/vfork/rfork will exhibit undefined behaviour. For example, the pthreads implementation on AIX will not end up delivering the signal to the expected thread, either. This was a bug in MySQL on AIX, for a while. I can't remember if it was me, Mark Peek, Paul Ozzello, or Jenifer Meyers that fixed the assumption, and sent the patch off to the MySQL folks, but it was one of us. FWIW, it's also incorrect to expect PTHREAD_SCOPE_SYSTEM to work on a user space pthreads implementation, which is permitted by the standard. It's also illegal set up your signal handler the way you have, given that the standard specifically states that it's unsafe to call some function in signal handlers, and you call one of them; realize that any system call you make will actually get the libc_r wrapped version, and therefore it should not be called in a signal handler in a threaded program, unless it's specifically allowed. Finally, signals are persistent conditions, not events. If you intend to write code where reaping your SIGCHLD handler, you *will* have to loop, as you do, on waitpid, following receipt of the signal, but the waiting should be accomplished via the signal handler setting a global volatile flag, and then the flag should be checked in the main loop of the program or a thread, somewhere, and the waitpid called from there. If you want to signal specific threads, you need to trampoline the signal from the process scope to a particular thread scope, using pthread_kill() after receiving the signal (this was the AIX MySQL fix). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Dag-Erling Smorgrav wrote: > Doug Barton <[EMAIL PROTECTED]> writes: > > On Tue, 28 Jan 2003, Garance A Drosihn wrote: > > > Well for one thing, if a given file has a lot of changes, then I > > > would like mergemaster to skip over the initial one-line change > > > that only tells me how some comment now has a new version-number > > > in it. > > This is an oft-requested feature, but I'm not sure how best to implement > > it. > > Look up the -I option in the diff(1) man page. I didn't say I don't know HOW to implement it, I said I didn't know how BEST to implement it. You snipped the part of my e-mail where I explained the issues. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChip driver("fla").
Dag-Erling Smorgrav wrote: > David Yeske <[EMAIL PROTECTED]> writes: > > I still use this. Users will not suddenly quit using hardware that > > works, they will start using a different OS that works with it, or > > they will be stuck trying to continue to support an old version of > > FreeBSD because it works with it. > > Read the announcement again. FreeBSD 5.x will still have DoC support, > which means you have at least two years to grow tired of it before we > stop putting out 5.x releases. By that time you will hopefully have > realised it is a dead-end technology and switched to something that > works. Why announce an intent to kill something that works? Do we just not "like" DoC, as a matter of public policy? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
On Monday 03 February 2003 07:35 am, Dag-Erling Smorgrav wrote: > Doug Barton <[EMAIL PROTECTED]> writes: > > On Tue, 28 Jan 2003, Garance A Drosihn wrote: > > > Well for one thing, if a given file has a lot of changes, then I > > > would like mergemaster to skip over the initial one-line change > > > that only tells me how some comment now has a new version-number > > > in it. > > > > This is an oft-requested feature, but I'm not sure how best to implement > > it. Allow users to pass "regexps to ignore" as an option? similar to: diff --ignore-matching-lines="\$FreeBSD:" ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
Doug Barton <[EMAIL PROTECTED]> writes: > I didn't say I don't know HOW to implement it, I said I didn't know how > BEST to implement it. You snipped the part of my e-mail where I explained > the issues. I don't see the problem, you don't need to run diff twice... no more than you already do (any reason why you don't use cmp instead of diff on line 815?) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[PATCH] PPP in -direct mode does not execute any chat scripts
Dear Hackers,
Please find attached patch that adds new option to the PPP.
run-scripts-in-direct-mode
Default: Disabled. This allows to run chat scripts in
direct mode.
did i miss anything? objections? comments? reviews?
thanks,
max
I'm working on the Bluetooth stack for FreeBSD and currently
doing testing for new in-kernel RFCOMM code. RFCOMM is a way
to emulate serial link over Bluetooth.
In particular Bluetooth spec defines two RFCOMM based profiles
LAN (Network Access profile) and DUN (DialUp Networking profile).
Both profiles use PPP.
My current in-kernel RFCOMM code provides SOCK_STREAM sockets
interface, i.e. when application wants to talk RFCOMM it just
opens a socket. The next step is to run PPP, so the launcher
program opens RFCOMM connection then dup() socket to stdin and
stdout and exec() PPP in direct mode.
Everything works great for the LAN profile, where null-modem
connection is assumed and both client and server start talking
PPP right after RFCOMM connection is established.
However the DUN profile is more tricky. In this scenario client
just connected to the virtual serial port on the server. Now to
start PPP session client must "dial a number". i.e. there is
still need for a little chat script.
Here is an example:
1) I'd like to use my GPRS and Bluetooth enabled cell phone to
access the Internet
2) I open a RFCOMM connection to the cell phone and get connected
to the virtual serial port on the cell phone.
3) Now i must dial a "special" GRPS number, i.e. something like
ATD*98***1# and wait for CONNECT string from the phone
4) Now i can talk PPP.
So the questions is: would it be possible to enable PPP chat
in "direct" mode? Is there any reason to not allow this? It
seems 'login' script would do just fine. Is there any other/
better way to do this? One possible option right now is to
execute /bin/chat from the launcher program before executing
PPP, but i'd rather keep all chat scripts in PPP.
thanks,
max
diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h Mon Feb 3 10:34:44 2003
+++ ppp/bundle.hMon Feb 3 10:36:56 2003
@@ -44,16 +44,17 @@
#define OPT_LOOPBACK 0x0040
#define OPT_PASSWDAUTH 0x0080
#define OPT_PROXY 0x0100
#define OPT_PROXYALL 0x0200
#define OPT_SROUTES0x0400
#define OPT_TCPMSSFIXUP0x0800
#define OPT_THROUGHPUT 0x1000
#define OPT_UTMP 0x2000
+#define OPT_RSIDM 0x4000 /* run-scripts-in-direct-mode */
#define MAX_ENDDISC_CLASS 5
#define Enabled(b, o) ((b)->cfg.opt & (o))
/* AutoAdjust() values */
#define AUTO_UP1
#define AUTO_DOWN 2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c Mon Feb 3 10:34:45 2003
+++ ppp/command.c Mon Feb 3 10:57:05 2003
@@ -2851,29 +2851,32 @@
{"loopback", NULL, OptSet, LOCAL_AUTH, "Loop packets for local iface",
"disable|enable", (const void *)OPT_LOOPBACK},
{"passwdauth", NULL, OptSet, LOCAL_AUTH, "Use passwd file",
"disable|enable", (const void *)OPT_PASSWDAUTH},
{"proxy", NULL, OptSet, LOCAL_AUTH, "Create a proxy ARP entry",
"disable|enable", (const void *)OPT_PROXY},
{"proxyall", NULL, OptSet, LOCAL_AUTH, "Proxy ARP for all remote hosts",
"disable|enable", (const void *)OPT_PROXYALL},
+ {"run-scripts-in-direct-mode", NULL, OptSet, LOCAL_AUTH,
+ "Run char scripts in direct mode", "disable|enable",
+ (const void *)OPT_RSIDM},
{"sroutes", NULL, OptSet, LOCAL_AUTH, "Use sticky routes",
"disable|enable", (const void *)OPT_SROUTES},
{"tcpmssfixup", "mssfixup", OptSet, LOCAL_AUTH, "Modify MSS options",
"disable|enable", (const void *)OPT_TCPMSSFIXUP},
{"throughput", NULL, OptSet, LOCAL_AUTH, "Rolling throughput",
"disable|enable", (const void *)OPT_THROUGHPUT},
{"utmp", NULL, OptSet, LOCAL_AUTH, "Log connections in utmp",
"disable|enable", (const void *)OPT_UTMP},
#ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
#else
-#define OPT_MAX 11
+#define OPT_MAX 12
#endif
{"acfcomp", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
"Address & Control field compression", "accept|deny|disable|enable",
(const void *)NEG_ACFCOMP},
{"chap", "chap05", NegotiateSet, LOCAL_AUTH | LOCAL_CX,
"Challenge Handshake Authentication Protocol", "accept|deny|disable|enable",
(const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb 3 10:34:45 2003
+++ ppp/datalink.c Mon Feb 3 11:03:48 2003
@@ -956,17 +956,18 @@
free(dl);
return result;
}
void
datalink_Up(struct datalink *dl, int runscripts, int packetmode)
{
- if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
+ if ((dl->physical->type & PHYS_DEDICATED) ||
+ ((dl->physical->type & PHYS_DIRECT) && !Enabled(dl->bundle, OPT_RSIDM)))
/* Ignore scripts */
runscripts = 0;
switch (dl->state) {
case DATALINK_CLOSED:
Re: [PATCH] PPP in -direct mode does not execute any chat scripts
In message: <[EMAIL PROTECTED]> Maksim Yevmenkin <[EMAIL PROTECTED]> writes: : Dear Hackers, : : Please find attached patch that adds new option to the PPP. : : : run-scripts-in-direct-mode : Default: Disabled. This allows to run chat scripts in : direct mode. : : did i miss anything? objections? comments? reviews? Maybe it would be better to call this "force-scripts" or something more general purpose so that one could force the use of scripts anywhere. Making direct mode have a special case override seems a little too restrictive. The heart of the patch would become: - if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED)) + if (!Enabled(dl->bundle, OPT_FORCE_SCRIPTS) && + (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED)) /* Ignore scripts */ runscripts = 0; with corresponding changes to the docs, defines, etc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH] PPP in -direct mode does not execute any chat scripts
Maksim Yevmenkin wrote: > Please find attached patch that adds new option to the PPP. > > run-scripts-in-direct-mode > Default: Disabled. This allows to run chat scripts in > direct mode. > > did i miss anything? objections? comments? reviews? First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's his baby, and he's the active maintainer. Rest of comments: Actually, why doesn't "-direct" allow a chat script by default? The man page doesn't document that as a side-effect of "-direct", only of "-dedicated", but it's been there since the import. Should this really be a "negotiate" section command, rather than just a command or a "set" command? Also, there are only two other commands even have a "-" in them, and both of them only have one (just seems a little long, compared to, say, "rsid" or "direct-with-script", or even "force-script"). Personal preference: don't make it conditional on "-direct", let it also work with "-dedicated", and call it "force-script" or something, instead. The man page should be updated -- including the undocumented side-effect of "-direct" disabling scripts). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChip driver("fla").
On Mon, Feb 03, 2003 at 10:05:54AM -0800, Terry Lambert wrote: > Dag-Erling Smorgrav wrote: > > David Yeske <[EMAIL PROTECTED]> writes: > > > I still use this. Users will not suddenly quit using hardware that > > > works, they will start using a different OS that works with it, or > > > they will be stuck trying to continue to support an old version of > > > FreeBSD because it works with it. > > > > Read the announcement again. FreeBSD 5.x will still have DoC support, > > which means you have at least two years to grow tired of it before we > > stop putting out 5.x releases. By that time you will hopefully have > > realised it is a dead-end technology and switched to something that > > works. > > > Why announce an intent to kill something that works? > > Do we just not "like" DoC, as a matter of public policy? I think phk has a good explaination: :The driver in the tree works with the M-systems devices I have to :test with, but M-Systems have neither sent me the necessary software :updates nor hardware samples of the latest generation of the DoC :and I have received no emails from people who were stuck because :of this. : :Combine this with the fact that the DoC is a CPU-poll technology :where you busy-wait for the flash devices to do their thing, rather :than get an interrupt when they are done, I think we can safely say :that the DoC is well past its prime time. -gordon msg39589/pgp0.pgp Description: PGP signature
[PATCH2] PPP in -direct mode does not execute any chat scripts
Dear Brian and Hackers,
Please find updated proposed version of the patch. As suggested by
Warner option has been renamed to 'force-sripts' and now works for
both 'direct' and 'dedicated' modes. Also as suggested by Terry the
man page has been updated to document side effect of 'direct'.
-direct
This is used for receiving incoming connections. ppp ignores the
``set device'' line and uses descriptor 0 as the link. ppp will
never use any configured chat scripts unless ``force-scripts''
option has been enabled.
If callback is configured, ppp will use the ``set device'' infor-
mation when dialing back.
-dedicated
This option is designed for machines connected with a dedicated
wire. ppp will always keep the device open and will never use
any configured chat scripts unless ``force-scripts'' option has
been enabled.
force-scripts
Default: Disabled. Forces execution of the configured chat
scripts in direct and dedicated modes.
Please find attached patch that adds new option to the PPP.
run-scripts-in-direct-mode
Default: Disabled. This allows to run chat scripts in
direct mode.
did i miss anything? objections? comments? reviews?
First comment: run it past Brian Somers <[EMAIL PROTECTED]>; it's
his baby, and he's the active maintainer.
I have sent him e-mail.
Rest of comments:
Actually, why doesn't "-direct" allow a chat script by default?
The man page doesn't document that as a side-effect of "-direct",
only of "-dedicated", but it's been there since the import.
Should this really be a "negotiate" section command, rather than
just a command or a "set" command?
Also, there are only two other commands even have a "-" in them,
and both of them only have one (just seems a little long, compared
to, say, "rsid" or "direct-with-script", or even "force-script").
Personal preference: don't make it conditional on "-direct", let
it also work with "-dedicated", and call it "force-script" or
something, instead.
done
The man page should be updated -- including the undocumented
side-effect of "-direct" disabling scripts).
done
thanks
max
diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h Mon Feb 3 10:34:44 2003
+++ ppp/bundle.hMon Feb 3 14:08:06 2003
@@ -44,16 +44,17 @@
#define OPT_LOOPBACK 0x0040
#define OPT_PASSWDAUTH 0x0080
#define OPT_PROXY 0x0100
#define OPT_PROXYALL 0x0200
#define OPT_SROUTES0x0400
#define OPT_TCPMSSFIXUP0x0800
#define OPT_THROUGHPUT 0x1000
#define OPT_UTMP 0x2000
+#define OPT_FORCE_SCRIPTS 0x4000 /* force chat scripts */
#define MAX_ENDDISC_CLASS 5
#define Enabled(b, o) ((b)->cfg.opt & (o))
/* AutoAdjust() values */
#define AUTO_UP1
#define AUTO_DOWN 2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c Mon Feb 3 10:34:45 2003
+++ ppp/command.c Mon Feb 3 14:26:37 2003
@@ -2830,16 +2830,19 @@
return 0;
}
static struct cmdtab const NegotiateCommands[] = {
{"filter-decapsulation", NULL, OptSet, LOCAL_AUTH,
"filter on PPPoUDP payloads", "disable|enable",
(const void *)OPT_FILTERDECAP},
+ {"force-scripts", NULL, OptSet, LOCAL_AUTH,
+ "Force execution of the configured chat scripts", "disable|enable",
+ (const void *)OPT_FORCE_SCRIPTS},
{"idcheck", NULL, OptSet, LOCAL_AUTH, "Check FSM reply ids",
"disable|enable", (const void *)OPT_IDCHECK},
{"iface-alias", NULL, IfaceAliasOptSet, LOCAL_AUTH,
"retain interface addresses", "disable|enable",
(const void *)OPT_IFACEALIAS},
#ifndef NOINET6
{"ipcp", NULL, OptSet, LOCAL_AUTH, "IP Network Control Protocol",
"disable|enable", (const void *)OPT_IPCP},
@@ -2861,19 +2864,19 @@
{"tcpmssfixup", "mssfixup", OptSet, LOCAL_AUTH, "Modify MSS options",
"disable|enable", (const void *)OPT_TCPMSSFIXUP},
{"throughput", NULL, OptSet, LOCAL_AUTH, "Rolling throughput",
"disable|enable", (const void *)OPT_THROUGHPUT},
{"utmp", NULL, OptSet, LOCAL_AUTH, "Log connections in utmp",
"disable|enable", (const void *)OPT_UTMP},
#ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
#else
-#define OPT_MAX 11
+#define OPT_MAX 12
#endif
{"acfcomp", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
"Address & Control field compression", "accept|deny|disable|enable",
(const void *)NEG_ACFCOMP},
{"chap", "chap05", NegotiateSet, LOCAL_AUTH | LOCAL_CX,
"Challenge Handshake Authentication Protocol", "accept|deny|disable|enable",
(const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb 3 10:34:45 2003
+++ ppp/datalink.c Mon Feb 3 14:17:52 2003
@@ -956,17 +956,18 @@
free(dl);
return result;
}
void
datalink_Up(struct datalink *dl, int runscripts, int packetmode)
{
- if (dl->physical->type & (PHYS_DIRECT|PHYS_DEDICATED))
+ if (!Enabled(dl->bundle, OPT_FORCE_SCRIPTS) &&
+ (d
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
Maksim Yevmenkin wrote: > force-scripts >Default: Disabled. Forces execution of the configured chat >scripts in direct and dedicated modes. Outstanding! If Brian doesn't veto, I'd say it's gold, and someone should commit it; so I guess this fixes the last Bluetooth Cell phone PPP problem, right? PS: I can't believe that Warner and I came within one letter of suggesting the same option name. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
My un-trained eye says this is good. Thanks for turning around the feedback so quickly. Now, we wait for Brian to review it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChip driver("fla").
Gordon Tetlow wrote: > > Why announce an intent to kill something that works? > > > > Do we just not "like" DoC, as a matter of public policy? > > I think phk has a good explaination: > > :The driver in the tree works with the M-systems devices I have to > :test with, but M-Systems have neither sent me the necessary software > :updates nor hardware samples of the latest generation of the DoC That's more or less a "blackmail the vendor" reason. If that's the intent, then I guess we'll have to see if it works. 8-). > :and I have received no emails from people who were stuck because > :of this. Or in other words: "despite these handicaps, no one is complaining that it's not working, so the lack of direct vendor support for the FreeBSD project, specifically, hasn't really damaged the ability of people to use the driver". > :Combine this with the fact that the DoC is a CPU-poll technology > :where you busy-wait for the flash devices to do their thing, rather > :than get an interrupt when they are done, I think we can safely say > :that the DoC is well past its prime time. That's a "we just don't like it" argument; I can respect not liking it, and complaining bitterly about it in the driver comments, like some of Bill Paul's infamous driver comments. FWIW: most crypto accelerators don't raise interrupts, either. It seems to be a common hardware vendor disease, to assume that the most important thing a computer can ever do is sit around waiting for their hardware to get done doing its thing, making polling it a requirement. But if that's the argument for removing it, then it's probably time to remove the ability to use non-DMA IDE drives from the ATA driver, and kill all the ethernet drivers that have alignment requirements for their DMA engines, making m_pullup copies necessary, and yanking all drivers that do destructive probes, and getting rid of the F00F workaround, and yanking all support for things hung off the floppy controller, etc. etc.. All that could be justified using exactly the same argument. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Random disk cache expiry
On Friday 31 January 2003 03:47, David Schultz wrote: > You have found an optimal replacement algorithm for the case of > repeated sequential reads. In fact, if you know in advance what > the access pattern is going to be, it is *always* possible to find > an optimal replacement algorithm. Specifically, you always > replace the block in the cache that will not be used for the > longest time in the future. > > If you want the system to always cache the right thing in the > general case, the only hint you would need to provide the system > is a reference string specifying the predicted access pattern. > (If I were to do this, my first reaction would be to encode it as > an FSA.) If that proves to be infeasible, I'm sure there are ways > to approximate the same thing. The hard parts, I think, would be > teaching the VM system to use the new information, and gathering > statistics from which you form your hints. I wouldn't even begin to try and deduce the access pattern from statistics, that sounds hard. In many cases, the application knows in advance what the access pattern will be. I think someone else in the thread has suggested having hints attached to the file as one option and I think the app itself should be able to signal it's intention to repeatedly read the file. I think trying to encode generalised access patterns is maybe not such a win. You could end up using a lot of memory storing the access pattern and a lot of effort encoding things as FSAs. Also the FSA has to be able to pick not just the block that won't be used for the longest time but it also has to pick a block that is actually in memory and for a more general access pattern this is not necessarily easy. Coping with reading a file straight through, several times is relatively common and can be encoded very easily and without much memory and assuming the file is not being accessed non-sequentially by another process, then picking the correct block is easy. Anyway, it's all academic for me really as I don't even run BSD and although I can write it when I have to, I don't find C anywhere near as much fun as Perl. I just thought it was an interesting question. I should probably go and get my coat now ;-) F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
The classic Unix including BSD4.4 UNIX is now under a BSD-like license too (finding it is another issue though ;). Anyone from those days remembers anything that might be worth resurrecting? cheers, Pedro. --- "James P. Howard II" <[EMAIL PROTECTED]> ha scritto: > Pedro F. Giffuni said: > > That's very cool! Congratulations! > > > > NetBSD has a BSD sort, I understand it's based on > the > > Minix version, so we are getting very near to > cleaning > > all the utilities from the GPL. > > I looked at doing sort some time ago, but that was > before Minix went BSDL. > I also had a almost-complete (missing two > functions) version of dc(1), > but lost it in a hard-disk crash. I never got > around to redoing it. > Perhaps I will again soon. > > Jamie > > __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
>The classic Unix including BSD4.4 UNIX is now under a >BSD-like license too (finding it is another issue >though ;). Kirk McKusick sells a CD-ROM collection containing all the CSRG distributions: https://www.mckusick.com/csrg/ Pretty much everything that had to be GNUified in BSD/386 and friends (thanks to the Death Star's lawyers) can be found in all its glory on the CDs. And thanks to Caldera, it can now be freely distributed. A lot of the CSRG code is missing functionality that we've picked up along the way, and much of it is pre-ANSI C, so there's work to be done to bring it up to date. Regardless, the CSRG code is a good starting point for a lot of things. (For example, I'm currently about half way through getting troff updated.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
Terry, Maksim Yevmenkin wrote: force-scripts Default: Disabled. Forces execution of the configured chat scripts in direct and dedicated modes. Outstanding! If Brian doesn't veto, I'd say it's gold, and someone should commit it; so I guess this fixes the last Bluetooth Cell phone PPP problem, right? seems like it :) just got report back from one of the testers. he got connected to the internet over his T39m bluetooth enabled cell phone. the cool thing is that you can make CSD, GPRS or HSCSD calls. its just a matter of init string you send to the phone :) still waiting on t68i and Nokia 7650 reports. PS: I can't believe that Warner and I came within one letter of suggesting the same option name. 8-) 8-). :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChipdriver("fla").
On Mon, 2003-02-03 at 18:06, Terry Lambert wrote: > But if that's the argument for removing it, then it's probably > time to remove the ability to use non-DMA IDE drives from the > ATA driver, and kill all the ethernet drivers that have alignment > requirements for their DMA engines, making m_pullup copies > necessary, and yanking all drivers that do destructive probes, > and getting rid of the F00F workaround, and yanking all support > for things hung off the floppy controller, etc. etc.. > > All that could be justified using exactly the same argument. It's great to hear you volunteering to maintain this driver, Terry. Thanks so much! --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
Maksim Yevmenkin wrote: > seems like it :) just got report back from one of the testers. > he got connected to the internet over his T39m bluetooth enabled > cell phone. the cool thing is that you can make CSD, GPRS or HSCSD > calls. its just a matter of init string you send to the phone :) > still waiting on t68i and Nokia 7650 reports. What kind of security negotiation occurs between devices, or can I use anyone's cell phone, as long as we are in the same restaurant, and I get a table in the middle? 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChipdriver("fla").
Nat Lanza wrote: > > But if that's the argument for removing it, then it's probably > > time to remove the ability to use non-DMA IDE drives from the > > ATA driver, and kill all the ethernet drivers that have alignment > > requirements for their DMA engines, making m_pullup copies > > necessary, and yanking all drivers that do destructive probes, > > and getting rid of the F00F workaround, and yanking all support > > for things hung off the floppy controller, etc. etc.. > > > > All that could be justified using exactly the same argument. > > It's great to hear you volunteering to maintain this driver, Terry. > > Thanks so much! Code that works doesn't *need* a maintainer. Neither does it need to be deprecated. When it quits working in a non-obvious way (e.g. not as a result of someone changing an interface out from under it, and failing to fix it up with the rest of the code), a maintainer will step forward and volunteer by submitting a patch to un-break it, or it will be time to deprecate it. Worst case, someone who cares very much about it will not have the skill to fix it, and will hire someone to fix it for them. That's how Open Source projects work. Arbitrarily diking out working code is bad policy. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: [PATCH2] PPP in -direct mode does not execute any chat scripts
Terry, > > seems like it :) just got report back from one of the testers. > > he got connected to the internet over his T39m bluetooth enabled > > cell phone. the cool thing is that you can make CSD, GPRS or HSCSD > > calls. its just a matter of init string you send to the phone :) > > still waiting on t68i and Nokia 7650 reports. > > What kind of security negotiation occurs between devices, or > can I use anyone's cell phone, as long as we are in the same > restaurant, and I get a table in the middle? 8-) 8-). you can if person with the cell phone is stupid :) and you do not have to get table in the middle. you have to be within ~10 meters radius. you also can get access to person's address book, calendar etc. as well :) all authentication and encryption based around link keys. one link key for each pair of devices. link key can be: 1) programmed into device itself (up to 16 keys) 2) can be requested from the user via HCI events 3) can be generated from the PIN code, PIN code is requested from the user via HCI event. normally what happens is: 1) device A tries to connect to device B 2) device B now looks for the link key that corresponds to device A's BDADDR. if found then key is used 3) if no link key found then both device A and device B locally generate Link_Key_Request event 4) both device A and B either get the keys from user A and user B, or if there is still no link key user sends Link_Key_Negative_Reply command 5) if no link key was received then both devices locally generate PIN_Code_Request 6) now both user A and user B have to enter PIN codes. the link key will be calculated from the PIN code. if no PIN code exists then user sends PIN_Code_Negative_Reply command to the device. this is implemented inside hcsecd. the user has option to disable authentication and in this case anyone can connect and no link key is required. also user can prevent device from peforming inquiry scan, i.e. the device will not respond to inquiry requests from other devices. user also can prevent device from performing page scans, i.e. device will not accept connections. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
At 9:12 AM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Dag-Erling Smorgrav wrote:
Doug Barton <[EMAIL PROTECTED]> writes:
> On Tue, 28 Jan 2003, Garance A Drosihn wrote:
> > Well for one thing, if a given file has a lot of changes, then I
> > would like mergemaster to skip over the initial one-line change
> > that only tells me how some comment now has a new version-number
> > in it.
> >
> > This is an oft-requested feature, but I'm not sure how best to
> > implement it.
>
Look up the -I option in the diff(1) man page.
I didn't say I don't know HOW to implement it, I said I didn't know
how BEST to implement it. You snipped the part of my e-mail where I
explained the issues.
I happen to be updating my system tonight, so when it came to the
mergemaster step I first modified the script. I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
worked the way I wanted it to work. From my skimming of the script,
I do not see how this change would cause problems for any other
processing. However, it's possible I'm missing something. If so, my
gut reaction is that if a lot of FreeBSD users are requesting this,
then we should figure out how to make it happen -- one way or another.
I suppose we should also change the 'absolute diff first' part to
include that, or people will be asked about merging a file, only
to be shown a file which apparently has zero changes.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen. Shouldn't that be moved
inside the
( ... ) | ${PAGER}
lines? And (IMO) delete one of the blank lines that are printed
out between the separator and the "Displaying differences" line.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Technical Differences of *BSD and Linux
> > > 4. Any chance of merging the very best part of each kernel? > > > 5. Or is it possible to do so? > > > > No, I don't forsee merging. der Mouse pointed out the GPL issue, which is > > one where I think the BSD and Linux folks will just agree to disagree. > > Besides some big issues of ideology, there is also the issue of some strong > personalities ...as evidenced by Theo de Raadt's rather helpful post, and also evidenced by the BSD's continued slide into technological irrelevance, despite the fantastic and superior work of a few good hackers. I've been a die-hard FreeBSD sysadmin for nine years now (and OpenBSD for awhile until the caustic attitudes there encouraged me to fsck my OpenBSD servers), but bullshit holier-than-thou posts like Theo's are not only *not* going to win converts, but they seriously malign the rest of the community. Eventually, the die-hards will die hard, and the lack of new competent BSD hackers will seal the coffin...the BSD sysadmin will be sent packing > To the original poster: This kind of posting is very unhelpful. If you > want to learn about the different systems, subscribe to some of the mailing > lists for each group, and watch for a while so that you can build your own > understanding of what is going on in the respective groups. In other words, except for the *hacker/*tech lists, there is no such thing as a stupid question. In the *hacker/*tech lists, there are very few who have achieved the greatness required to engage in discourse...so shut up, stupid. Perhaps it might behoove the respective lists to create a, uh, sheesh...document (I'd hate to use such a passe' term like FAQ), of questions which should never be asked on the list because they'd cause too many flames and not enough "valid dialogue". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing GNU grep with UNIX grep.
On 2003-02-03 18:51 +, Lyndon Nerenberg wrote: > >The classic Unix including BSD4.4 UNIX is now under a > >BSD-like license too (finding it is another issue > >though ;). > > Kirk McKusick sells a CD-ROM collection containing all the CSRG > distributions: > > https://www.mckusick.com/csrg/ > > Pretty much everything that had to be GNUified in BSD/386 and friends > (thanks to the Death Star's lawyers) can be found in all its glory on > the CDs. And thanks to Caldera, it can now be freely distributed. > > A lot of the CSRG code is missing functionality that we've picked up > along the way, and much of it is pre-ANSI C, so there's work to be done > to bring it up to date. Regardless, the CSRG code is a good starting > point for a lot of things. (For example, I'm currently about half way > through getting troff updated.) I think tjr mentioned he had started converting a few utilities. Anyone picking things up may want to pick up where he left off. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Technical Differences of *BSD and Linux
>> [...the whole thread re BSD vs Linux...] > [...] Eventually, the die-hards will die hard, and the lack of new > competent BSD hackers will seal the coffin...the BSD sysadmin will be > sent packing I've seen it said that ego will be the death of BSD. The more I see of BSD the more I believe it. In most respects I don't care much for the GPL, but this is one of the really good effects it has: it keeps people from using "you gotta splash my name all over everything" licenses on their stuff. I just looked at the INSTALL.txt file from the most recent NetBSD/sparc release - a rough eyeball count found 79 individuals' names in the "legal mumbo-jumbo" section; I may have skipped a few or duplicated a few, but I'm sure the count is well over 50, probably over 70. And that's not counting institutions, just individuals. I consider that totally ludicrous. (Hackerdom is a gift culture; you attain status by giving away, not by attaching strings.) Given their common heritage, I imagine the other BSDs are similar, though I haven't specifically checked (NetBSD just happens to be the one I know well enough to be able to find the relevant file quickly). Of course, Linux's use of the GPL ensures that OS hackers who want that kind of egoboo won't go there; thus, they end up with the BSDs, because there isn't much else in the open-source OS world. Pity, too, because the BSD world has a lot to offer, technically, but it's shooting itself in the foot, socially and legally, by permitting this sort of chest-beating. >> To the original poster: This kind of posting is very unhelpful. If >> you want to learn about the different systems, subscribe to some of >> the mailing lists for each group, and watch for a while so that you >> can build your own understanding of what is going on in the >> respective groups. Arrogant and unhelpful as this is, there is a grain of truth lurking in it: nobody but you can ever tell you quite what the difference is for your purposes. Asking what the differences between Linux and BSD are is a bit like asking what the differences between automobiles and pogo-sticks are: sometimes you want one and sometimes you want the other, and nobody can tell you what the relevant differences between them for you are, except by chance, without knowing what differences you care about. But it does strike me as a singularly unhelpful way to put it. The original question can - and in this case quite likely did - come from a degree of ignorance that doesn't even know yet what questions are sensible to ask, and while I can't claim to speak for any of the projects in question, it does seem to me that such people are exactly the people whom the projects need most to welcome. Of course, I've also seen it said (privately) that the original message could well have been a troll. If so, it was rather well-done, and even if it it was, that doesn't invalidate the legitimate discussion that arose as a result. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Technical Differences of *BSD and Linux
der Mouse wrote: > In most respects I don't care much for the GPL, but this is one of the > really good effects it has: it keeps people from using "you gotta > splash my name all over everything" licenses on their stuff. I just > looked at the INSTALL.txt file from the most recent NetBSD/sparc > release - a rough eyeball count found 79 individuals' names in the > "legal mumbo-jumbo" section; I may have skipped a few or duplicated a > few, but I'm sure the count is well over 50, probably over 70. And > that's not counting institutions, just individuals. I consider that > totally ludicrous. (Hackerdom is a gift culture; you attain status by > giving away, not by attaching strings.) Given their common heritage, I > imagine the other BSDs are similar, though I haven't specifically > checked (NetBSD just happens to be the one I know well enough to be > able to find the relevant file quickly). There is a good reason for this. It has to do with there not being a legal entity to which rights can be assigned. The original BSD code, with 7 or 8 exceptions, like the NFS code with the Genentech Copyright on it, or stdio.h with Chris Torek's Copyright on it, was all: * This product includes software developed by the University of * California, Berkeley and its contributors. When people donated code, they entered into a legal agreement with the University, in which they assigned rights to the code to the University, in exchange for legal protection from tort liability. If Copyright law were to acknowledge the existance of Public Domain, by providing liability protection for authors whose code was used by third parties, resulting in damages, then almost every BSD developer I'm aware of wuld release their code as public domain, instead. Notice that the authors of the GPL, the FSF, have this same legal assignmet ofrights issue with accepting contributed code into their source tree. All of the GCC developers have an assignment of rights on file with the FSF, or they would not be permitted to be GCC developers. > Of course, Linux's use of the GPL ensures that OS hackers who want that > kind of egoboo won't go there; thus, they end up with the BSDs, because > there isn't much else in the open-source OS world. This is actually incorrect. At one point in time, the email address of the driver authors was printed out in boot messsages, under Linux. They had a "flag day" in which Linus removed all the printf's. This flag day was actually commercially motivated. The truth is that some people will piss on their code so that you know it smells like themselves, just as some people in positions of authority in projects will piss on contributed patches to make it smell like themselves. It doesn't matter if the project is Linux or FreeBSD or TheNextGreatProject. > Pity, too, because > the BSD world has a lot to offer, technically, but it's shooting itself > in the foot, socially and legally, by permitting this sort of > chest-beating. This is Richard Stallman's argument against the original four clause BSD license, specifically the "claim credit" clause, clause 3. There are three problems with this argument: 1) It was invalid, for the entire time that CSRG existed, and there was a single statement that would have been necessary in advertising. 2) The clause only triggered if you mentioned "feature or use of this software", according to the license. So unless you went out of your way to say something like "New! With CAM support by HD Associates!", or something equally idiotic in your advertising, you would not need to reproduce the "This product includes software developed by HD Associates". 3) Most new software these days is contributed without the caluse, and uses a two cause a three clause license, instead, omitting the "disagreeable" clause. > Arrogant and unhelpful as this is, there is a grain of truth lurking in > it: nobody but you can ever tell you quite what the difference is for > your purposes. This is also incorrect. It's like going into a sports arena in New York and delaying a hockey game so you can get on the P.A. and ask "Which is better, Catholicism or Judaeism?". Many people can tell you very easily what the differences are, but to do so would be to incite a riot. People would defend the shorcomings of their OS relative to the other, simply because they already had an emotional investment in it, and the discussion would not stay the course on the basis of technical merit. Some "peacemakers" would post things like "it depends" or try to give equal credit to both sides, etc., and this would just piss off more religious zealots. The reason people generally ignore these postings is that the postings are generally made by jackasses, with the intent of inflaming enmity betwen the camps involved, and then sitting back and gleefully watching the fireworks. Rarely is the question ever asked hone
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Amit Rao wrote: > On Monday 03 February 2003 07:35 am, Dag-Erling Smorgrav wrote: > > Doug Barton <[EMAIL PROTECTED]> writes: > > > On Tue, 28 Jan 2003, Garance A Drosihn wrote: > > > > Well for one thing, if a given file has a lot of changes, then I > > > > would like mergemaster to skip over the initial one-line change > > > > that only tells me how some comment now has a new version-number > > > > in it. > > > > > > This is an oft-requested feature, but I'm not sure how best to implement > > > it. > > Allow users to pass "regexps to ignore" as an option? > similar to: diff --ignore-matching-lines="\$FreeBSD:" ? That actually has promise... probably as a mergemasterrc option. I'll give it some thought. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
More compartive power/performance results (was Re: Lower power SMP boxes?)
test #1 test #2 Power (seconds) (bandwidth) (load on UPS) DELL2550 / 1.2 GHz 0.62253MB/sec 12% Pentium 4 / 1.3 GHz 0.74500MB/sec ? 650 MHz Celeron P3 1.30145MB/sec ? EPIA M 9000 / 933 w/fan 1.55 72MB/sec 3.5-4% EPIA 5000 / 533 fanless 2.50 65MB/sec 2% test #1 (run several times so the file is cached) /usr/bin/time -l sort /usr/share/dict/words > /dev/null test #2 (run several times so the file is cached) dd if=bigfile of=/dev/null bs=64k count=1024 Power: Difference in load percentage based on querying the UPS, An APC Smart-UPS 1400 RM. The Celeron is an HP Pavilion and the P4 is a Sony VAIO desktop. Sorry, no power readings there, I can't shut down the sony and the HP is in a different room. I've added EPIA M 9000 tests to the list (I just got it in today). I'm actually surprised that the M 9000 doesn't have better ram bandwidth with its DDR ram, but the cpu suds are a definite improvement over the EPIA 5000 and power consumption is still reasonably low. The EPIA 5000 still seems to have the best performance/power ratio though. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
> I happen to be updating my system tonight, so when it came to the
> mergemaster step I first modified the script.
Cool... contrary to popular opinion, I do like UI feedback. :)
> I added:
> -I '$FreeBSD:.*$'
> to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
> worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.) I also
think it's unlikely that you'd run into a version-string only diff in a
recent current -> recent current upgrade. It's these that are the chief
problem I'm concerned about.
> From my skimming of the script, I do not see how this change would cause
> problems for any other processing. However, it's possible I'm missing
> something.
What do you think mm should do if the only diff between two files is the
cvs ID? This comes up inside a branch if a change is checked in, then
backed out. Of course, it happens a lot when upgrading from 4 to 5 for
example.
> If so, my gut reaction is that if a lot of FreeBSD users are requesting
> this, then we should figure out how to make it happen -- one way or
> another.
The request I actually get is that if the only diff is the cvs ID, that mm
should do with it. Most commonly, just install the file
(which I'm opposed to on principle, and by fundamental mm design). Trying
to deal rationally with this scenario is why I'd have to add at least one
more diff to the process.
1. Are the cvs id's different?
2. If so, is that the only difference? <--- new
3. If cvs ID is not the only diff, display that to the user.
> I suppose we should also change the 'absolute diff first' part to
> include that, or people will be asked about merging a file, only
> to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
> I'd also note that the separator line (=) is usually scrolled
> off the window for me. Not much point to a good eye-catching line
> if the line is usually not on the screen.
That's actually a good thing. The is for those cases where a diff is
smaller than one screenful. It was requested by users to give more visual
definition to that scenario, and also make logs of mm sessions easier to
parse. Passing it to PAGER when the diff already fills a page is a waste
of screen space.
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying mergemaster behavior
At 10:36 PM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
> I added:
-I '$FreeBSD:.*$'
> to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to
> have worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.)
I do not care to see what the version-string is, and I certainly
don't need to see the two un-changing lines before and after the
version-string. When you also count the diff-output line which
gives the line numbers of the change, that's a total of six lines
which appear on the screen and which give me (IMO) very little
useful information.
Try -I and watch how it behaves. It isn't exactly what I was asking
for, but it is close enough that I think it would be a helpful step
forward from the present behavior.
> From my skimming of the script, I do not see how this change would
> cause problems for any other processing.
What do you think mm should do if the only diff between two files
is the cvs ID?
see below.
> I suppose we should also change the 'absolute diff first' part
> to include that, or people will be asked about merging a file,
> only to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
There's a section of mergemaster that starts out with the comment
"Do an absolute diff first to see if the files are actually different".
What I was saying is we should add the same -I argument to that
diff command, so that if a file only differs by the version string,
then the "absolute diff" will not consider it a change.
In thinking about it now, I realize that I (personally) would
prefer that mergemaster would just install the file in that case,
but the result of adding the -I to that diff command is that the
file would be quietly skipped over. I could live with that too,
but I'd feel better to have it automatically installed. JMO.
> If so, my gut reaction is that if a lot of FreeBSD users are
> requesting this, then we should figure out how to make it
> happen -- one way or another.
What I was getting at is that mergemaster is going to be run fairly
often by a significant number of freebsd users. If we need make some
changes to make that process more pleasant, then I think we should
feel free to do that. If people aren't happy with how -I works, then
we should consider adding some different option to diff which will
do the job.
I would rather see a few lines added to diff, then having the
script do a bunch of back-flips and multiple runs of diff to get
the desired behavior. I'd also prefer those lines added to diff
than to say "it's too hard to get the desired behavior, so let's
not bother".
The request I actually get is that if the only diff is the cvs ID,
that mm should do with it. Most commonly, just
install the file (which I'm opposed to on principle, and by
fundamental mm design).
Mergemaster has the -'i' option to automatically install new files.
Perhaps the same option could control whether it automatically
installs files where the only change is to the version string
which is in a comment line.
Trying to deal rationally with this scenario is why I'd have to
add at least one more diff to the process.
1. Are the cvs id's different?
2. If so, is that the only difference? <--- new
3. If cvs ID is not the only diff, display that to the user.
What I would ideally like is some option to diff where diff itself
understands what a version-string is, and it prints out a header
line that includes the version-string change. But the way -I
works is fairly close to what I want, and is probably less
objectionable than adding some rather specialized option to diff.
> I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen.
That's actually a good thing. [...] Passing it to PAGER when the
diff already fills a page is a waste of screen space.
That line is more useful to me than the six lines of space used up
by telling me that the file is now 1.7.12 instead of 1.7.10. This
is my opinion. Other people have theirs, this one is mine.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Technical Differences of *BSD and Linux
[off-list]
> If Copyright law were to acknowledge the existance of Public Domain,
> by providing liability protection for authors whose code was used by
> third parties, resulting in damages, then almost every BSD developer
> I'm aware of wuld release their code as public domain, instead.
How does the present way work any better? How does "Copyright 2003 by
J. Fred Muggs" with a BSD-style license grant provide any greater
liability protection in the face of such a scenario? Under what
jurisdiction(s)?
>> Of course, Linux's use of the GPL ensures that OS hackers who want
>> that kind of egoboo won't go there; thus, they end up with the BSDs,
>> because there isn't much else in the open-source OS world.
> This is actually incorrect. At one point in time, the email address
> of the driver authors was printed out in boot messsages, under Linux.
Fine - but there was no binding requirement that this be done, as you
note:
> They had a "flag day" in which Linus removed all the printf's.
The driver authors didn't get to do the "you gotta credit me" thing,
which was my point. Credit is fine. Using the legal mallet of
copyright law to _demand_ credit is what I was referring to.
>> Pity, too, because the BSD world has a lot to offer, technically,
>> but it's shooting itself in the foot, socially and legally, by
>> permitting this sort of chest-beating.
> This is Richard Stallman's argument against the original four clause
> BSD license, specifically the "claim credit" clause, clause 3. There
> are three problems with this argument:
> 1)It was invalid, for the entire time that CSRG existed, and
> there was a single statement that would have been necessary in
> advertising.
At most, this is a problem there _was_ with the argument; it is not a
problem there _is_ with the argument.
> 2)The clause only triggered if you mentioned "feature or use of
> this software", according to the license. So unless [...]
Or if you said "our OS is based on {Free,Net,Open}BSD", which is much
more plausible.
And, perhaps more important, for someone without the legal staff to
investigate exactly what counts for these purposes (eg, freeware
projects), you have to either recite the claimer or skate the legally
thin ice of not doing so when maybe you need to.
> 3)Most new software these days is contributed without the caluse,
> and uses a two cause a three clause license, instead, omitting
> the "disagreeable" clause.
Good for their authors.
This has no bearing on what I said: the BSD world is shooting itself in
the foot, socially and legally, by permitting such licenses. Except
for code infected by the original four-clause BSD license, such credit
clauses have never been required; yet, some seventy-plus people have
used them, and BSD has let them - NetBSD, at least, and I've seen not
even a claim that the other BSDs are any different in this regard.
>> Arrogant and unhelpful as this is, there is a grain of truth lurking
>> in it: nobody but you can ever tell you quite what the difference is
>> for your purposes.
> This is also incorrect. It's like going into a sports arena in New
> York and delaying a hockey game so you can get on the P.A. and ask
> "Which is better, Catholicism or Judaeism?".
No, that might be a fairer analogy if the original question had been
asked on, say, a woodworking list. (At least with respect to
[EMAIL PROTECTED], where I saw it; I don't know the other lists well
enough to say how on-topic it was for them.)
Also, the original message - I went back and reread it - did not ask
which was better, as your analogy does; it asked for a discussion of
the differences. Closer might be to ask a group of priests and rabbis
"what are the differences between Catholicism and Judaism?".
> Many people can tell you very easily what the differences are, but to
> do so would be to incite a riot. [...]
All reasonable and (depressingly) probably true.
But none of those are reasons to ridicule the question, much less the
questioner, just reasons to answer off-list.
>> Of course, I've also seen it said (privately) that the original
>> message could well have been a troll. If so, it was rather
>> well-done,
> No, actually, it was poorly done.
Well-done as in being a convincing imitation of the serious variant of
the same question, not well-done as in an being effective at inciting
flamewars.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
