Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2 support for distribution patches)
In message <Pine.BSF.4.21.0001221703020.4454-10@localhost>, Alex Zepeda wro te: } On Sat, 22 Jan 2000, Rod Taylor wrote: } } > Personally, I'd like to see less stuff in the system source for } > smaller installs and lower compile time leaving it up to me to } > customize the individual stuff thats installed. Unless bzip is used } > by > 99.9% of the FreeBSD installs, I'm willing to let it } > 'auto-install itself'. } } What if we began to use bzip2 instead of gzip for things like man pages, } or releases, etc? I did that (for man pages) out of curiosity a year or two ago, and the difference was negligible. bzip2 seems to do better on bigger files as a (very) general rule than on smaller ones. } I think gzip is somewhat like compress, in that it might never go away } completely, but it's generally been superceded by (IMO) bzip2. I don't agree at all, and all you have to do is visit a few web sites and ftp sites' download areas to see why. It's just not ubiquitous, or even close. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
In message <[EMAIL PROTECTED]>, Wes Peters wrote: } Lyndon Nerenberg wrote: } > } > >>>>> "Mark" == Mark Murray <[EMAIL PROTECTED]> writes: } > } > Mark> o A username may only be checked $number times per } > Mark> $timeperiod; after that, _all_ answers are silently } > Mark> converted to "no". } > } > Umm, massive DOS hole. } } Per username. If you publish your userlist, you're an idiot. The } daemon should also immediately go into "breakin evasion mode" for } all invalid usernames, answering the requests very slowly. You don't have to publish a userlist in order for some of that kind of information to leak out. Besides, by answering very slowly for invalid usernames you just gave the bad guys a way to deduce your user list anyway. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
In message <[EMAIL PROTECTED]>, Chris Costello wrote: } On Sun, Sep 12, 1999, Peter Wemm wrote: } > Now that I think about it, it shouldn't be too hard (TM) to finish off the } > /proc/pid/cmdline stuff so that ps didn't need to access /mem and didn't } > need setgid at all. } }What about the `e' flag? What about people who don't use /proc? Maybe I'm misreading; is the plan to make ps work (at least with most of the bells and whistles) only with /proc, or is the plan to make it an option to either strip the setgid and use proc, or to leave it and use kmem? -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp over pty: trying to detect CD
Running -current from this afternoon, I am having a strange symptom with ppp over a pty; ppp does not detect that the pty does not support carrier, and will cycle once per second waiting for CD to appear. Putting ``set cd off'' in my ppp.conf for that target fixed the problem, but I thought I'd mention it nonetheless, since that didn't used to be required. Certainly not all that big a deal, but I thought it was worth a mention. FreeBSD 4.0-CURRENT #13: Sat Dec 11 20:31:42 CST 1999 The section from my ppp.conf: vpn: set ipcpretry 1000 set lcpretry 1000 set timeout 0 set ifaddr 192.168.1.2/0 192.168.1.1/0 255.255.255.0 set cd off <- this guy fixed the problem enable lqr accept lqr set openmode passive set log phase ipcp Connect tun Command add 192.168.2.0/24 HISADDR and the syslog with debugging turned on, with no "set cd" in the config: Dec 11 20:48:20 woodstock ppp[3106]: Phase: Using interface: tun1 Dec 11 20:48:20 woodstock ppp[3106]: Phase: deflink: Created in closed state Dec 11 20:48:20 woodstock ppp[3106]: tun1: Command: vpn: add 192.168.2.0/24 HISADDR Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: wrote 140: cmd = Add, dst = 2a8c0, gateway = 101a8c0 Dec 11 20:48:20 woodstock ppp[3106]: tun1: Phase: PPP Started (direct mode). Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: Select changes time: no Dec 11 20:48:20 woodstock ppp[3106]: tun1: Phase: bundle: Establish Dec 11 20:48:20 woodstock ppp[3106]: tun1: Phase: deflink: closed -> opening Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: deflink: Input is a tty (/dev/ttyp0) Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: deflink: tty_Create: physical (get): fd = 0, iflag = 0, oflag = 2, cflag = 4b00 Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: deflink: physical (put): iflag = 201, oflag = 2, cflag = 3cb00 Dec 11 20:48:20 woodstock ppp[3106]: tun1: Phase: deflink: Connected! Dec 11 20:48:20 woodstock ppp[3106]: tun1: Phase: deflink: opening -> carrier Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: deflink: Using tty_Timeout [0x8072d44] Dec 11 20:48:20 woodstock ppp[3106]: tun1: Debug: Waiting for carrier Dec 11 20:48:21 woodstock ppp[3106]: tun1: Debug: deflink: Using tty_Timeout [0x8072d44] Dec 11 20:48:21 woodstock ppp[3106]: tun1: Debug: Waiting for carrier [ and on and on and on ] -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
In message <97a8ca5bf490d211a94ff6c2e55d097...@s-lmh-wi-900.corpnet.at>, La davac Marino wrote: } BTW, has chown been "fixed" to the ludicrous SysV semantics that } the root and owner can chown a file? If so, the latter has to be } disabled in presence of quotas on the volume--otherwise: } } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero >>big_file } } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /var/db/pkg/.mkversion
In message <19990401052839.d11...@futuresouth.com>, "Matthew D. Fuller" wrote: } [ Yes, I'm sticking my nose in where it probably doesn't belong and } should get chopped off for it. It's a hobby ;] } } On Thu, Apr 01, 1999 at 02:36:14AM -0800, a little birdie told me } that Satoshi - the Wraith - Asami remarked } > } > The same situation arises whether the version info is in /var/db/pkg } > or /some/other/place. It has been pointed out many times in the past } > that we need something to ensure bsd.port.mk can synchronize itself } > with the rest of the system (simply because there are too many people } > who cvsup one without the other). } > } > The question is, can I ask you to make sysinstall write some kind of } > version info that can be used by bsd.port.mk to identify the age of } > the system? } } This would require a little more work on the 'back' side, but what would } be so hard about just checking $Id$ strings around the .mk files? If } not for the revision, at least for the date. I think that's asking for trouble - it'll lose if someone keeps their .mk files in their own RCS (I do this for some files; admittedly not for the .mk files, but I could see someone doing that). -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: correction for find(1)'s man page
In message <199901180357.taa22...@vashon.polstra.com>, John Polstra wrote: } In article <36a0fc11.8b22d...@cybercable.fr>, } Thierry Herbelot wrote: } > Hello } > } > I was reading the man page for find(1), looking for the precise option } > to follow symbolic links. } > } > This option is -follow, of course, but it is not described in the man } > page } } Huh? The correct options are the first three options described in } the man page: } -H The -H option causes the file information and file type (see }stat(2)) returned for each symbolic link specified on the command }line to be those of the file referenced by the link, not the link }itself. If the referenced file does not exist, the file informa- }tion and type will be for the link itself. File information of }all symbolic links not on the command line is that of the link }itself. What this doesn't explicitly say is that it causes find(1) to actually follow the symlink and recursively descend the target tree (if the link points to a directory); I assume that's the behavior the original poster wanted. Near the bottom of the find(1) manpage (on my -stable system), is this: Historically, the -d, -h and -x options were implemented using the pri- maries ``-depth'', ``-follow'', and ``-xdev''. These primaries always ``-h'' there should read ``-H''; -h is an unknown option to find(1). -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
In message , Richar d Wackerbarth wrote: } } On Wed, 10 Feb 1999, John Fieber wrote: } } > On Wed, 10 Feb 1999, jack wrote: } > } > > If /etc/rc.conf only contains changes from the defaults when } > > man something_or_other tells the user to find and edit } > > something_or_other_flags in /etc/rc.conf the entry won't be } > > there to edit. } > } > Why must it contain only changes? Is there any reason it } > couldn't be a copy of the default rc.conf on a new installation? } } Alternately, it could be a copy of the default file with every item } commented out. That would provide the clues for those who need to } edit values and still not mess up the default behavior of a new install } with old options that might have changed but were not explicitly } overridden. But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Dangerously looking glitch (4.0-STABLE)
In message <[EMAIL PROTECTED]>, Maxim Sobolev wrote: } This is a multi-part message in MIME format. } --3D64CAE46133EFA188180FFD } Content-Type: text/plain; charset=koi8-r } Content-Transfer-Encoding: 7bit } } Hi, } } I've tried to track down why my own script which is cleaning non-matching } distfiles from time to time produce incorrect results (just cvsup'ed 4.0). } After some digging I've found that this bug could be easily reproduced by doi } ng } "find -exec md5" on large set of files several times consequiently, and then } comparing results. You can see that md5 checksum of the one of the files is How many in a "large set"? I tried 10 passes on my 4.0-stable machine and was not able to replicate your results, though I only have about 500 files in my distfiles. I tried the same in /usr/src, and in another area with both large and small files (393,000 total), all of which came up clean. I think you have a hardware problem somewhere :( -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangerously looking glitch (4.0-STABLE)
In message <[EMAIL PROTECTED]>, Maxim Sobolev wrote: } Frank Nobis wrote: } } > On Wed, Apr 05, 2000 at 07:13:29AM -0500, Jon Hamilton wrote: } > > } > > up clean. I think you have a hardware problem somewhere :( } > } > That is very likely a hardwre problem. I have a nfs server under 3.4-S } > here running, It was easy to crash the system with much I/O over nfs } > on a 100M Ethernet connection. (I did a dump and the machine paniced) } > } > The same over a slower 10M ethernet, but it took longer to crash. } > } > Now I replaced a very old adaptec 1542cf with a 2940U. I did the same } > stress test, but got no more panics. Even a load of 80% interrupts } > didn't kill the machine. } > } > Maybe you have a similar problem. } } It is unlikely, because I've never seen this problem previously when 3.[01234 } ] } was installed on this hardware. Hardware does fail over time; just because it performed OK in the past doesn't mean that something hasn't gone bad since. I suppose it could be a problem with one of the drivers for your particular setup; is it feasable for you to try booting an older version (even from floppy) of FreeBSD and try the test again? -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
In message <[EMAIL PROTECTED]>, Richard Wackerbarth wrote } > > Do we really need 5 year old history? } > } > Yes. } I don't disagree that we need to maintain the history. } } I do, however, question the policy that REQUIRES EVERYONE to maintain that } much history. I've been following this thread at some distance for a while, and I don't understand your definition of ``everyone''. Aside from developers, who do you feel is a good candidate to track the entire CVS repository, rather than using CVSUP or some other method to get only the tree they are interested in? I'm not trying to be snide; it's possible that I'm missing some element of your argument, but I think using the term ``everyone'' is overstating the case considerably. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
