Re: Generic config file parser?
On Mon, May 29, 2000 at 02:00:37AM +0200, A G F Keahan wrote: > > This may be a silly question, but is there such a thing?Almost every > program that I know uses configuration files, often in different, > incompatible formats. I personally prefer Samba/Wine-style config man 3 property for a start, anyways. -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mktemp() vs. mkstemp()
On Sun, May 14, 2000 at 01:56:28PM -0700, Kris Kennaway wrote: > > > integer file descriptor whereas normal people use FILE * pointers, > > including the author of this port. How about an mkftemp() which wraps > > around mkstemp() and does an fdopen()? > > This would be completely non-portable - if you really need this, make one > yourself and add it to a library distributed with your code. It's certainly not like it would be the first non-portable function we've added. Where adding functions to libraries encourages better coding practices, I'm (often) in favour of it, especially if it encourages more secure coding practices. Ultimately everyone benefits, and the pain is short-term. -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make question
On Fri, May 12, 2000 at 11:05:03PM +0200, Samuel Tardieu wrote: > > but make prefers the .ads.lo rule instead of the .adb.lo, despites the > order in the .SUFFIXES. Using "make -d s" to trace dependencies and rules, > I get: FWIW, this works correctly on ~3.4-R. It must have gotten broken somewhere between there and here. If you can locate the commit that actually broke it (or even tell us the version strings (`strings $(which make) | grep \$FreeBSD`) for your version), that would help to fix it. > I am having difficulties to implement the following rule in BSD make: to > produce file foobar.o, then start from foobar.adb if it exists, foobar.ads > otherwise. I want this to be compatible with both BSD and GNU make. > > I tried: > > .SUFFIXES: .adb .ads .lo > > .adb.lo: > > > .ads.lo: > > [...] > > SuffFindDeps (broca-exceptions.lo) > trying broca-exceptions.S...not there > trying broca-exceptions.adb...got it > using existing source broca-exceptions.ads > applying .ads -> .lo to "broca-exceptions.lo" > > broca-exceptions.adb has been found and should have been used, but > this "using existing source" message (coming after!) bugs me. The wrong > rule is then being selected. > > Any hint of where it can come from? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for advice on lpr/lpd changes
On Thu, May 11, 2000 at 04:43:25PM -0400, Garance A Drosihn wrote: > > Hmm. I always assumed that was for "big freebsd architectural > changes", as opposed to changes to a "little program" like lpr. I'd rather see a discussion about designing new features for lpr on -arch than I would see a discussion on, say, I dunno, maybe renaming all .s files to .S. > I have already noticed that send-pr patches are sometimes > committed almost instantly, and other times it's like pulling > teeth to get some attention for them... Don't feeling too guilty about politely knocking -committers over the head once-in-a-while. Just before weekends is probably a good time. ;-) -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for advice on lpr/lpd changes
On Wed, May 10, 2000 at 12:14:59PM -0400, Tim Vanderhoek wrote: > > > that will skip header pages or send them email. Does this seem > > like a reasonable idea, or should I approach this from another > > angle? > > If you are hoping to have a series discussion, a carefully written ^^ serious > However, -hackers will get a greater number of opinions and ideas. I > would start at -hackers and then make a series proposal (possibly with ^^ serious -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for advice on lpr/lpd changes
On Wed, May 10, 2000 at 10:23:24AM -0400, Garance A Drosihn wrote: > > 1990's) with the extra features we've added. Once I have things > sorted out, I'll have a number of updates to offer. Cool! > that will skip header pages or send them email. Does this seem > like a reasonable idea, or should I approach this from another > angle? If you are hoping to have a series discussion, a carefully written message to the -arch list may work. The -arch list is meant to be a low(er)-volume, higher information-density list for discussing architectural changes. It would also have the advantage that more committers will follow the discussion meaning that your patches will get reviewed (and probably committed) sooner. However, -hackers will get a greater number of opinions and ideas. I would start at -hackers and then make a series proposal (possibly with patches already written) at -arch. Finished patches are best sent via send-pr(1) where they will eventually be addressed (although the response-time for send-pr(1) is regrettably long...) -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PR's and patches
> In the last episode (May 09), Garance A Drosihn said: > > > > I used 'lynx' to download the PR, and it seemed to come down > > correctly (tab-characters where I'd expect them, etc), but the patch Use `w3m -dump http://www.FreeBSD.org/cgi/query-pr.cgi?pr= | patch`. It will correctly download the file for you. Lynx just makes a mess of the thing no matter what you try to do. The patch(1) is smart enough to realize that the patch is indented by four spaces and smart enough to realize that some of the text is not part of the patch. -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
On Mon, Jan 03, 2000 at 08:29:00PM -0800, Ronald F. Guilmette wrote: > > >> >Question 1: What is the reason for FreeBSD to differ from other platforms > >> >and not follow the IEEE standard by default? > >> >(Please forgive me if this is an ignorant question.) [...] > >That's actually a trick question. When I researched this a few years > >ago, I found that *no* system other than NetBSD starts up in an > >IEEE-conformant mode. To wit: > > > >* iBCS2/SCO, SVR4 and FreeBSD leave exceptions unmasked. This should be a FAQ. Over time, many people have expressed their preferrence that exceptions be masked by default in FreeBSD. They are not by conscious decision. The situation can be summed by the following quote from bde: "I don't plan to change the exception handling until the other [libm ANSI conformance bugs] are fixed." The short answer is that porting is made easiest by simply calling fpsetmask(0) on FreeBSD. I couldn't find any really good references explaining all the exact details, but... References to two message by bde that are a little more explicit: Message-ID: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> You can use the interface at http://www.FreeBSD.org/search to search for messages by Message-ID. Also, the following PRs are relevant: URL: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=105 URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=229 There are many more references in the archives for the self-motivated. -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Fri, Sep 03, 1999 at 01:10:32AM -0700, Satoshi - Ports Wraith - Asami wrote: > >> differences are 1) entries in inetd.conf are sample entries only, 2) >> ports have no way of adding those entries to inetd.conf themselves >> (since touching /etc is illegal). > > Uh, you're contradicting yourself. Touching /etc is not illegal. Well, ok, the word "illegal" was a little strong. However, this is a long-standing policy from at least 1995/6. See the following relevant message-IDs: 199509201159.eaa04...@silvia.hip.berkeley.edu You state that touching /etc is "hardly sacred" but that it is wise to avoid it due to the large contingent of people who feel strongly against it. The contingent of people appears to have included markm and ollivier, but not Terry Lambert who advocated "templating" so that ports could modify /etc but still have a read-only root fs. I could not find the previous discussion you refer to -- it was probably only in -hackers and not -ports). gdcvv0n...@ache.dialup.ru A reference to the ultimate goal of switching /etc to be read-only is made by ache. [It does not appear he agreed with the "large contingent" mentioned above, though]. 199601221813.taa04...@keltia.freenix.fr A reference to the policy of not allowing ports to touch /etc is made by ollivier. I believe this is the message that I read and remembered. I suppose I could have chosen a wimpier word than "illegal", but we have tried to avoid schmucking with /etc for quite a while... I believe this is a good thing to avoid. > Besides those that add uid/gids, most shell ports add entries to > /etc/shells. Yes, I know that. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Fri, Sep 03, 1999 at 01:10:32AM -0700, Satoshi - Ports Wraith - Asami wrote: > >> differences are 1) entries in inetd.conf are sample entries only, 2) >> ports have no way of adding those entries to inetd.conf themselves >> (since touching /etc is illegal). > > Uh, you're contradicting yourself. Touching /etc is not illegal. Well, ok, the word "illegal" was a little strong. However, this is a long-standing policy from at least 1995/6. See the following relevant message-IDs: [EMAIL PROTECTED] You state that touching /etc is "hardly sacred" but that it is wise to avoid it due to the large contingent of people who feel strongly against it. The contingent of people appears to have included markm and ollivier, but not Terry Lambert who advocated "templating" so that ports could modify /etc but still have a read-only root fs. I could not find the previous discussion you refer to -- it was probably only in -hackers and not -ports). [EMAIL PROTECTED] A reference to the ultimate goal of switching /etc to be read-only is made by ache. [It does not appear he agreed with the "large contingent" mentioned above, though]. [EMAIL PROTECTED] A reference to the policy of not allowing ports to touch /etc is made by ollivier. I believe this is the message that I read and remembered. I suppose I could have chosen a wimpier word than "illegal", but we have tried to avoid schmucking with /etc for quite a while... I believe this is a good thing to avoid. > Besides those that add uid/gids, most shell ports add entries to > /etc/shells. Yes, I know that. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 04:37:11PM +0200, Sheldon Hearn wrote: > > It's certainly something I'd like to take a shot at, yes. Perhaps I'm > going about this the wrong way. Perhaps I should first provide a knob > that allows sendmail to be run non-priveledged. Once that's done, add a > user for it to run as. And then once that new user has had considerable time to settle, rip all the user/group stuff from the mta ports and change them to use an arbitrary user/group that defaults to whatever you added for sendmail. But if you go about it this way, give the new user:group time to settle so that ripping the pkg/INSTALL scripts (which are used for both binary packages _and_ build-from-source ports) breaks only a few people. [I think this has been mentioned before, too, but don't try to change the ids qmail uses or the author may try to stand on certain legal rights he has retained.] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 10:01:55AM +0200, Sheldon Hearn wrote: > > > OTOH, I can see that having a common user:group would be useful and > > make some things easier, too. > > And that's all I want -- to make things easier. :-) I don't think you should add usernames/groups to the base system just for the sake of ports. 1) There are more ports than just the MTAs that require their own usernames/groups. Are you going to add these to the base system, too? I realize that we already have some precedence for this; see for example inetd.conf which contains sample entries for ports. The differences are 1) entries in inetd.conf are sample entries only, 2) ports have no way of adding those entries to inetd.conf themselves (since touching /etc is illegal). 2) The current system for having ports add their own usernames and groupnames is very simple. It is a little messy in that there are a number of different pkg/INSTALL scripts, some of them broken to various degrees. Simply adding an mta username:groupname won't solve that problem. Suppose you do add an mta username/groupname to the base system. Ports will still need to keep their various pkg/INSTALL scripts, since the ports need to work on older releases of FreeBSD that do not have the new username and groupname. You would need to modify the pkg/INSTALL scripts to use the new username/groupname and (depending on how broken the script is to start with) add it only if necessary. What about existing admins who have their systems configured with the existing usernames and groupnames? These people will have problems when they upgrade the port (possibly annoying problems). Will the ports be modified so that they use their earlier custom username/groupname in preference to the standardized username/groupname? This is a lot of complexity you're adding simply for the sake of having a unified username and groupname added to the base system. 3) We try to keep the ports system roughly independent of the base system, and vice-a-versa. Do you plan to make sendmail use this new mta id (is that even possible?)? Or will this id be added solely for the use of the ports system? (Yes, I am aware of historical raisins such as the news id). If only the latter, then adding a new id is probably not a good idea. If what you want is to have all the MTAs run under a single user/group-name, then you should modify each of the ports. The ports can then add the user/group as necessary, which works for almost any release of FreeBSD. While you are doing this, you could also fix the ports to use a more-or-less common pkg/INSTALL script (although a copy should be carried with each port, rather than sharing only one copy); last time I looked at this, I came close to proposing an addition to bsd.port.mk, too. The only argument you've really made is that adding a user/group -name to the base system will make some things simpler. However, this also adds complexity elsewhere. Further, it is a fairly slippery slope. Adding user/group-names for every port wanting one is a fairly bad idea because of a) loss of single-point customizability for individual ports (eg. changing for local purposes the username used by a given port is now more work), b) backwards-compatibility requirements (ie. work on older releases of FreeBSD w/o custom uid/gid-s) of the ports system, and c) we may eventually collide with names added by admins on their own system (there is a de-facto standard of reserving the first 100 id # that helps lessen the likelihood of this, but it is i) only a de-facto standard, ii) only the first 100). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 04:37:11PM +0200, Sheldon Hearn wrote: > > It's certainly something I'd like to take a shot at, yes. Perhaps I'm > going about this the wrong way. Perhaps I should first provide a knob > that allows sendmail to be run non-priveledged. Once that's done, add a > user for it to run as. And then once that new user has had considerable time to settle, rip all the user/group stuff from the mta ports and change them to use an arbitrary user/group that defaults to whatever you added for sendmail. But if you go about it this way, give the new user:group time to settle so that ripping the pkg/INSTALL scripts (which are used for both binary packages _and_ build-from-source ports) breaks only a few people. [I think this has been mentioned before, too, but don't try to change the ids qmail uses or the author may try to stand on certain legal rights he has retained.] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 10:01:55AM +0200, Sheldon Hearn wrote: > > > OTOH, I can see that having a common user:group would be useful and > > make some things easier, too. > > And that's all I want -- to make things easier. :-) I don't think you should add usernames/groups to the base system just for the sake of ports. 1) There are more ports than just the MTAs that require their own usernames/groups. Are you going to add these to the base system, too? I realize that we already have some precedence for this; see for example inetd.conf which contains sample entries for ports. The differences are 1) entries in inetd.conf are sample entries only, 2) ports have no way of adding those entries to inetd.conf themselves (since touching /etc is illegal). 2) The current system for having ports add their own usernames and groupnames is very simple. It is a little messy in that there are a number of different pkg/INSTALL scripts, some of them broken to various degrees. Simply adding an mta username:groupname won't solve that problem. Suppose you do add an mta username/groupname to the base system. Ports will still need to keep their various pkg/INSTALL scripts, since the ports need to work on older releases of FreeBSD that do not have the new username and groupname. You would need to modify the pkg/INSTALL scripts to use the new username/groupname and (depending on how broken the script is to start with) add it only if necessary. What about existing admins who have their systems configured with the existing usernames and groupnames? These people will have problems when they upgrade the port (possibly annoying problems). Will the ports be modified so that they use their earlier custom username/groupname in preference to the standardized username/groupname? This is a lot of complexity you're adding simply for the sake of having a unified username and groupname added to the base system. 3) We try to keep the ports system roughly independent of the base system, and vice-a-versa. Do you plan to make sendmail use this new mta id (is that even possible?)? Or will this id be added solely for the use of the ports system? (Yes, I am aware of historical raisins such as the news id). If only the latter, then adding a new id is probably not a good idea. If what you want is to have all the MTAs run under a single user/group-name, then you should modify each of the ports. The ports can then add the user/group as necessary, which works for almost any release of FreeBSD. While you are doing this, you could also fix the ports to use a more-or-less common pkg/INSTALL script (although a copy should be carried with each port, rather than sharing only one copy); last time I looked at this, I came close to proposing an addition to bsd.port.mk, too. The only argument you've really made is that adding a user/group -name to the base system will make some things simpler. However, this also adds complexity elsewhere. Further, it is a fairly slippery slope. Adding user/group-names for every port wanting one is a fairly bad idea because of a) loss of single-point customizability for individual ports (eg. changing for local purposes the username used by a given port is now more work), b) backwards-compatibility requirements (ie. work on older releases of FreeBSD w/o custom uid/gid-s) of the ports system, and c) we may eventually collide with names added by admins on their own system (there is a de-facto standard of reserving the first 100 id # that helps lessen the likelihood of this, but it is i) only a de-facto standard, ii) only the first 100). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 08:27:38AM +1000, Andrew Reilly wrote: > > Another data point: qmail adds _seven_ new users, and one new > group. It has a very paranoid security model. > > I think that it uses a script to add them, but maybe I did it > myself. It was a while ago... The qmail port uses a script. The script uses pw. Note that qmail also has registered its uids and gids with the ports system. Because qmail has registered uids and gids, it is allowed to insist on getting a specific uid or gid number. I do not reccomend this for most ports. Most ports which require a uid or gid do not require a specific number (and thus do not require that the uid or gid be registered). These ports need merely add the required username or groupname from a pkg/INSTALL script. Qmail is an exception; qmail compiles the uid and gid numbers into itself. This caused the Linux package people much angst. :-) Of the many ports that require their own uid and gid, some of them are not good examples to follow. I believe qmail is ok (although it's pkg/INSTALL uses perl, which is sub-ideal). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 12:39:28AM +0200, Ollivier Robert wrote: > According to Sheldon Hearn: > > I plan to add a user ``smtp'' with UID 25 and a member of group > > ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is > > primarily for the convenience of maintainers of mail ports. Will ports adapt easily to this? Having ports add their own users and groups is fairly trivial. Using a single user:group could make some of the ports less standard (eg. most of the world does not run qmail under user ``smtp'' or group ``mail''). OTOH, I can see that having a common user:group would be useful and make some things easier, too. [I'm not saying I'm opposed; I'm asking if it really makes sense for the ports to use a single mta user:group ... I know some authors ( djb, of qmail [in]famy) would probably try to prohibit us from using a single user:group]. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 08:27:38AM +1000, Andrew Reilly wrote: > > Another data point: qmail adds _seven_ new users, and one new > group. It has a very paranoid security model. > > I think that it uses a script to add them, but maybe I did it > myself. It was a while ago... The qmail port uses a script. The script uses pw. Note that qmail also has registered its uids and gids with the ports system. Because qmail has registered uids and gids, it is allowed to insist on getting a specific uid or gid number. I do not reccomend this for most ports. Most ports which require a uid or gid do not require a specific number (and thus do not require that the uid or gid be registered). These ports need merely add the required username or groupname from a pkg/INSTALL script. Qmail is an exception; qmail compiles the uid and gid numbers into itself. This caused the Linux package people much angst. :-) Of the many ports that require their own uid and gid, some of them are not good examples to follow. I believe qmail is ok (although it's pkg/INSTALL uses perl, which is sub-ideal). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Thu, Sep 02, 1999 at 12:39:28AM +0200, Ollivier Robert wrote: > According to Sheldon Hearn: > > I plan to add a user ``smtp'' with UID 25 and a member of group > > ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is > > primarily for the convenience of maintainers of mail ports. Will ports adapt easily to this? Having ports add their own users and groups is fairly trivial. Using a single user:group could make some of the ports less standard (eg. most of the world does not run qmail under user ``smtp'' or group ``mail''). OTOH, I can see that having a common user:group would be useful and make some things easier, too. [I'm not saying I'm opposed; I'm asking if it really makes sense for the ports to use a single mta user:group ... I know some authors ( djb, of qmail [in]famy) would probably try to prohibit us from using a single user:group]. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Sat, Aug 28, 1999 at 05:45:05AM -0500, Mike Pritchard wrote: > > I vote for two spaces after the period before the start of a new sentence. > Even in the digital age, I've always found that the two spaces make > for better reading of text. I think that most of our formatting > tools do this too (please don't flame me if I'm wrong :-). The manpages screw it up sometimes. [It's probably fair to assume you know when they do, but anyways... -- A sentence ends .Ar here . But this new one has a single space preceeding it. -- -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
On Sat, Aug 28, 1999 at 05:45:05AM -0500, Mike Pritchard wrote: > > I vote for two spaces after the period before the start of a new sentence. > Even in the digital age, I've always found that the two spaces make > for better reading of text. I think that most of our formatting > tools do this too (please don't flame me if I'm wrong :-). The manpages screw it up sometimes. [It's probably fair to assume you know when they do, but anyways... -- A sentence ends .Ar here . But this new one has a single space preceeding it. -- -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Splash screen problem after being interrupted
On Thu, Aug 26, 1999 at 11:34:03PM -0700, Doug wrote: > Tonight while testing my rc file changes I decided to interrupt > the splash screen display I have to see the boot messages. I hit [...] > Obviously this is a "... well don't do that" case, but I'm not > sure it should be fatal. Hopefully this is of use to someone. It worked with the original splash kit patch from when 3.0 was -current. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Splash screen problem after being interrupted
On Thu, Aug 26, 1999 at 11:34:03PM -0700, Doug wrote: > Tonight while testing my rc file changes I decided to interrupt > the splash screen display I have to see the boot messages. I hit [...] > Obviously this is a "... well don't do that" case, but I'm not > sure it should be fatal. Hopefully this is of use to someone. It worked with the original splash kit patch from when 3.0 was -current. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
[Cc's trimmed] On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote: > > > > > > How 'bout "anyone who can kill the process holding the lock?" > > > > + file owner ( + root ). > > Which processes can't root kill? Zombies? :) > > Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't > > be able to do anything about it until either notifying me or notifying > > root about the process I accidentally left hanging. > > Hey, I'm the one who gave you write access to it. If I didn't want you > write-locking it, I wouldn't give you write access, now wood eye? Yes, but I wrote a program that knows when I move between here and Toronto. That program automatically updates ~wes/FreeBSDmarkers. Unfortunately, I left a small bug in that program (it doesn't unlock and it doesn't end itself). To make matters worse, since this was the iteration where I move to Toronto, I probably won't be reading mail for a couple days (or more). You'll have to try and contact root (or just crash the machine). Fortunately for you, r...@freebsd.org is fairly responsive... :) But in the meantime, everyone else, including you, is locked out of that file..which is pretty bad since my buggy program had another bug I forgot to mention: it accidentally removed all entries from the file except mine. I hope you don't use that file for anything important. Gosh, and I thought I was being smart by using mandatory locks so that your file would get badly damaged it someone else tried modifying it while my program also modified it. > Or better yet, implement file ACLs so I can grant read/write to everyone BUT > you. Of course, I can do that now by creating goup "nothoek" right? ;^) Well, that would work, too. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
[Cc's trimmed] On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote: > > > > > > How 'bout "anyone who can kill the process holding the lock?" > > > > + file owner ( + root ). > > Which processes can't root kill? Zombies? :) > > Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't > > be able to do anything about it until either notifying me or notifying > > root about the process I accidentally left hanging. > > Hey, I'm the one who gave you write access to it. If I didn't want you > write-locking it, I wouldn't give you write access, now wood eye? Yes, but I wrote a program that knows when I move between here and Toronto. That program automatically updates ~wes/FreeBSDmarkers. Unfortunately, I left a small bug in that program (it doesn't unlock and it doesn't end itself). To make matters worse, since this was the iteration where I move to Toronto, I probably won't be reading mail for a couple days (or more). You'll have to try and contact root (or just crash the machine). Fortunately for you, [EMAIL PROTECTED] is fairly responsive... :) But in the meantime, everyone else, including you, is locked out of that file..which is pretty bad since my buggy program had another bug I forgot to mention: it accidentally removed all entries from the file except mine. I hope you don't use that file for anything important. Gosh, and I thought I was being smart by using mandatory locks so that your file would get badly damaged it someone else tried modifying it while my program also modified it. > Or better yet, implement file ACLs so I can grant read/write to everyone BUT > you. Of course, I can do that now by creating goup "nothoek" right? ;^) Well, that would work, too. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tue, Aug 24, 1999 at 05:51:54PM -0400, Tim Vanderhoek wrote:
> >
> > How 'bout "anyone who can kill the process holding the lock?"
On further reflection, I'd go even further: anyone who can set the
lock can break the lock. Presumably if they know enough to explicitly
break the lock, then they know enough to know what they're doing.
This is more-or-less like a chmod("-w")
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tue, Aug 24, 1999 at 05:51:54PM -0400, Tim Vanderhoek wrote:
> >
> > How 'bout "anyone who can kill the process holding the lock?"
On further reflection, I'd go even further: anyone who can set the
lock can break the lock. Presumably if they know enough to explicitly
break the lock, then they know enough to know what they're doing.
This is more-or-less like a chmod("-w")
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote: > > > > I don't like restricting the breaking of mandatory locks to the > > superuser. It could be restricted to specific users (say file owner + > > root)... > > How 'bout "anyone who can kill the process holding the lock?" + file owner ( + root ). Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't be able to do anything about it until either notifying me or notifying root about the process I accidentally left hanging. [Not that I'm likely to ever need more than an advisory lock on that particular file, but the principle... :-] Hm. ``chmod go-"MayLock" ~wes/Fre*'' The sticky bit could be used. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote: > > > > I don't like restricting the breaking of mandatory locks to the > > superuser. It could be restricted to specific users (say file owner + > > root)... > > How 'bout "anyone who can kill the process holding the lock?" + file owner ( + root ). Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't be able to do anything about it until either notifying me or notifying root about the process I accidentally left hanging. [Not that I'm likely to ever need more than an advisory lock on that particular file, but the principle... :-] Hm. ``chmod go-"MayLock" ~wes/Fre*'' The sticky bit could be used. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
On Mon, Aug 23, 1999 at 12:28:32AM -0700, Christopher Seiwald wrote: > > The alteration that I've tried and tested is to have the isort bail > back to qsort if it does more than N swaps. I put N at 1024, which Perhaps a ratio: #comparisons : # swaps If the ratio gets too high, then bail. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote: > > In process-space, this is the kernel. In file-space, this should > be root. Processes that require mandatory locking must revoke > superuser before attempting locks. I don't like restricting the breaking of mandatory locks to the superuser. It could be restricted to specific users (say file owner + root)... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 03:28:01PM -0400, Garance A Drosihn wrote: > > Anyway, I am also puzzled as to why there would be much objection > to the option of mandatory locking. My initial systems-programming If you provide mandatory locks that can be broken, then many of the objections may disappear... Providing mandatory locks that can be broken would be rather useful, I think. Mandatory locks that cannot be broken are another matter... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
On Mon, Aug 23, 1999 at 12:28:32AM -0700, Christopher Seiwald wrote: > > The alteration that I've tried and tested is to have the isort bail > back to qsort if it does more than N swaps. I put N at 1024, which Perhaps a ratio: #comparisons : # swaps If the ratio gets too high, then bail. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote: > > In process-space, this is the kernel. In file-space, this should > be root. Processes that require mandatory locking must revoke > superuser before attempting locks. I don't like restricting the breaking of mandatory locks to the superuser. It could be restricted to specific users (say file owner + root)... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Mon, Aug 23, 1999 at 03:28:01PM -0400, Garance A Drosihn wrote: > > Anyway, I am also puzzled as to why there would be much objection > to the option of mandatory locking. My initial systems-programming If you provide mandatory locks that can be broken, then many of the objections may disappear... Providing mandatory locks that can be broken would be rather useful, I think. Mandatory locks that cannot be broken are another matter... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote: > > I don't care if most of the > directories called "gnu" in the current tree contain GPLd code. How I had to read your message about 4 or 5 times before I realized that "Oh, the ``gnu'' in the directory name doesn't mean it's GPL'd code". And that was cognition time with context...without my conclusion would have been reverse and erroneous. src/lib/libgnucompat seems to be the best suggestion so far. I wonder where the line between libgnucompat and libfreebsdextension is, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote: > > I don't care if most of the > directories called "gnu" in the current tree contain GPLd code. How I had to read your message about 4 or 5 times before I realized that "Oh, the ``gnu'' in the directory name doesn't mean it's GPL'd code". And that was cognition time with context...without my conclusion would have been reverse and erroneous. src/lib/libgnucompat seems to be the best suggestion so far. I wonder where the line between libgnucompat and libfreebsdextension is, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Thu, Aug 12, 1999 at 01:10:44AM +0200, Sheldon Hearn wrote: > > I'll feel more comfortable about letting them shoot their feet off if > you can point out _any_ way in which it might be beneficial for them to > do so. :-) I suggest that it would be beneficial for you to let them shoot off their feet... I have used legacy sysinstall to upgrade a live multiuser system before and will probably do so again. In my dictionary, "bleet" translates to "warn". Just make sysinstall bleet as you originally offered and everyone will be happy. :-) Hmm... "bleet"'s not in esr's hacker dictionary. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using legacy sysinstall to upgrade live system
On Thu, Aug 12, 1999 at 01:10:44AM +0200, Sheldon Hearn wrote: > > I'll feel more comfortable about letting them shoot their feet off if > you can point out _any_ way in which it might be beneficial for them to > do so. :-) I suggest that it would be beneficial for you to let them shoot off their feet... I have used legacy sysinstall to upgrade a live multiuser system before and will probably do so again. In my dictionary, "bleet" translates to "warn". Just make sysinstall bleet as you originally offered and everyone will be happy. :-) Hmm... "bleet"'s not in esr's hacker dictionary. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Results of investigating optimizing calloc()...
On Sat, Aug 07, 1999 at 12:46:05PM +1000, Chris wrote: > > > The issue is not speed, because this is something we do in the > > background when there's nothing else to do. The issue is to avoid > > thrashing the cache. [...] > Two things, You haven't considered SMP yet. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Results of investigating optimizing calloc()...
On Sat, Aug 07, 1999 at 12:46:05PM +1000, Chris wrote: > > > The issue is not speed, because this is something we do in the > > background when there's nothing else to do. The issue is to avoid > > thrashing the cache. [...] > Two things, You haven't considered SMP yet. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
On Mon, Aug 02, 1999 at 09:25:52AM +0200, Dag-Erling Smorgrav wrote: >(there were > places where make world would bomb because chflags doesn't work on [...] > (check the logs for Makefiles that use > chflags). [...] > r...@des ~# current -l -F Makefile chflags > src/Makefile.inc1 Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make world, if needed. [A make world actually works from usermode now with the right set of options (one of which is -DNOGAMES)]. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: readdirplus is very cool, any other nfs client suggestions?
On Mon, Aug 02, 1999 at 09:25:52AM +0200, Dag-Erling Smorgrav wrote: >(there were > places where make world would bomb because chflags doesn't work on [...] > (check the logs for Makefiles that use > chflags). [...] > root@des ~# current -l -F Makefile chflags > src/Makefile.inc1 Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make world, if needed. [A make world actually works from usermode now with the right set of options (one of which is -DNOGAMES)]. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote: > > > b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null > > b$ time grep '(vt100)|(printer)' longfile > /dev/null > > You think that's fair? Surely you can't expect Jamie's extended regex > support to outperform GNU's simple regex support? :-) GNU has no simple regex support. Actually, neither did Jamie's by the time I did that test, but I added the -E flag to make it obvious what was going on. :) I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote: > > > b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null > > b$ time grep '(vt100)|(printer)' longfile > /dev/null > > You think that's fair? Surely you can't expect Jamie's extended regex > support to outperform GNU's simple regex support? :-) GNU has no simple regex support. Actually, neither did Jamie's by the time I did that test, but I added the -E flag to make it obvious what was going on. :) I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > Funnily, I experience a near-doubling of running time with similar > patches. Incidentally, it seems that it's not possible to assume that our regex library is even anywhere in the same league as the GNU regex library. b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null real0m21.284s user0m22.034s sys 0m0.083s Now, with a profiled executable with optimization turned off it takes about 25 seconds. Regardless, it appears to spend 98% of its time in regexec(), which is good, since that's where it should be spending time. [I had been intending to combine multiple patterns, ultimately combining in a '\n' to avoid the memchr() in mmopen]. b$ time grep '(vt100)|(printer)' longfile > /dev/null real0m0.267s user0m0.109s sys 0m0.157s 98% * 20 = ~19... Without an improved regex library, any mildly complicated pattern will bring the new grep to its knees. This could be the dfa helping GNU grep more than having a better regexp library... Probably both. I wonder how well the devel/pcre port would do POSIX regular expressions. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > Funnily, I experience a near-doubling of running time with similar > patches. Incidentally, it seems that it's not possible to assume that our regex library is even anywhere in the same league as the GNU regex library. b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null real0m21.284s user0m22.034s sys 0m0.083s Now, with a profiled executable with optimization turned off it takes about 25 seconds. Regardless, it appears to spend 98% of its time in regexec(), which is good, since that's where it should be spending time. [I had been intending to combine multiple patterns, ultimately combining in a '\n' to avoid the memchr() in mmopen]. b$ time grep '(vt100)|(printer)' longfile > /dev/null real0m0.267s user0m0.109s sys 0m0.157s 98% * 20 = ~19... Without an improved regex library, any mildly complicated pattern will bring the new grep to its knees. This could be the dfa helping GNU grep more than having a better regexp library... Probably both. I wonder how well the devel/pcre port would do POSIX regular expressions. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > > it was VERY simple to do... and attached is the patch... this uses the > > option REG_STARTEND to do what the copy was trying to do... all of the > > code to use REG_STARTEND was already there, it just needed to be enabled.. > > Funnily, I experience a near-doubling of running time with similar > patches. Strange... His patches made grep on my system much faster than the original 0.10 and almost as fast as GNU grep. b$ /usr/bin/time ./grep-10 -e printer longfile > /dev/null 1.16 real 0.97 user 0.19 sys b$ /usr/bin/time ./grep-10-jmg -e printer longfile > /dev/null 0.48 real 0.43 user 0.04 sys b$ /usr/bin/time grep -e printer longfile > /dev/null 0.28 real 0.09 user 0.18 sys This is one of the original Celerons, FWIW. Once-in-a-while that gives me performance numbers somewhat different from any other Intel. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote: > > I said that I did not care whether the thing is inside or outside > the regexp library. Yes, although I think at this point it's obvious we're coming at this discussion from fairly different perspectives. By the time you brought-up complexity originally, I had more or less decided that I did not want to see the new grep imported without significant speed improvements and was concerned with how to improve grep. Your interest is in debating that point (fortunately arguing for the side I agree with :). > 4) grep -e 123 456 world.build [I assume "grep -e 123 -e 124 world.build"] > One can clearly see that GNU grep has a much better complexity in > the cases of longer patterns or multiple patterns with common > prefix. Alright, someone else already mentioned to me in email that I totally ignored what differences involved multiple patterns. Combining multiple patterns is a big win if those two patterns have a common prefix (I hadn't considered the case of similar patterns before, actually). Combining multiple patterns when they're dissimilar doesn't appear to help much (which is the only case I had considered -- my mistake, and also the reason I ignored what you said about multiple patterns). I'm surprised by the way GNU grep is able to handle longer patterns, and I probably wouldn't have noticed it unless I'd taken some time to examine the GNU source. Congratulations, you win. :) The rest of your lengthy message mostly goes on to repeat the fact that GNU grep is able to merge multiple patterns with a common prefix (and postfix?) to good effect. > It also shows that the new grep spends a lot of time in an activity > not related to the search itself, since it does multiple patterns by Well, duh. This is really why my reaction to "complexity analysis" is (still) what it is. Complexity analysis is almost only useful for comparing two different algorithms and the fact that the new grep spends a lot of time doing things other than pattern searching is quite obvious after a casual perusal of the source. Complexity analysis does not (directly) help improving an algorithm. With the possible exception of the idea of merging common prefixes, most of this is not useful (at this stage) to improving grep. If I was going to propose replacing the existing GNU grep, I would (and always would have) done considerable more speed trials than the simple one in my last message. > It would seem that GNU grep is superior in the case of partial > matches without a full match too, but the standard deviation for the That is almost certainly something inside the regex library, which I have repeatedly said I'm not interested in even looking at. If our regex library is too slow, then we need to look into the newer one the Henry Spencer is rumoured to be sitting on. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > > it was VERY simple to do... and attached is the patch... this uses the > > option REG_STARTEND to do what the copy was trying to do... all of the > > code to use REG_STARTEND was already there, it just needed to be enabled.. > > Funnily, I experience a near-doubling of running time with similar > patches. Strange... His patches made grep on my system much faster than the original 0.10 and almost as fast as GNU grep. b$ /usr/bin/time ./grep-10 -e printer longfile > /dev/null 1.16 real 0.97 user 0.19 sys b$ /usr/bin/time ./grep-10-jmg -e printer longfile > /dev/null 0.48 real 0.43 user 0.04 sys b$ /usr/bin/time grep -e printer longfile > /dev/null 0.28 real 0.09 user 0.18 sys This is one of the original Celerons, FWIW. Once-in-a-while that gives me performance numbers somewhat different from any other Intel. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote: > > I said that I did not care whether the thing is inside or outside > the regexp library. Yes, although I think at this point it's obvious we're coming at this discussion from fairly different perspectives. By the time you brought-up complexity originally, I had more or less decided that I did not want to see the new grep imported without significant speed improvements and was concerned with how to improve grep. Your interest is in debating that point (fortunately arguing for the side I agree with :). > 4) grep -e 123 456 world.build [I assume "grep -e 123 -e 124 world.build"] > One can clearly see that GNU grep has a much better complexity in > the cases of longer patterns or multiple patterns with common > prefix. Alright, someone else already mentioned to me in email that I totally ignored what differences involved multiple patterns. Combining multiple patterns is a big win if those two patterns have a common prefix (I hadn't considered the case of similar patterns before, actually). Combining multiple patterns when they're dissimilar doesn't appear to help much (which is the only case I had considered -- my mistake, and also the reason I ignored what you said about multiple patterns). I'm surprised by the way GNU grep is able to handle longer patterns, and I probably wouldn't have noticed it unless I'd taken some time to examine the GNU source. Congratulations, you win. :) The rest of your lengthy message mostly goes on to repeat the fact that GNU grep is able to merge multiple patterns with a common prefix (and postfix?) to good effect. > It also shows that the new grep spends a lot of time in an activity > not related to the search itself, since it does multiple patterns by Well, duh. This is really why my reaction to "complexity analysis" is (still) what it is. Complexity analysis is almost only useful for comparing two different algorithms and the fact that the new grep spends a lot of time doing things other than pattern searching is quite obvious after a casual perusal of the source. Complexity analysis does not (directly) help improving an algorithm. With the possible exception of the idea of merging common prefixes, most of this is not useful (at this stage) to improving grep. If I was going to propose replacing the existing GNU grep, I would (and always would have) done considerable more speed trials than the simple one in my last message. > It would seem that GNU grep is superior in the case of partial > matches without a full match too, but the standard deviation for the That is almost certainly something inside the regex library, which I have repeatedly said I'm not interested in even looking at. If our regex library is too slow, then we need to look into the newer one the Henry Spencer is rumoured to be sitting on. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote: > > > > DES tells me he has a new version (0.10) which mmap()s. It supposedly > cuts the run time down significantly, I do not have the numbers in front > of me. I do. Still far too slow. I'll work on this tomorrow, since that seems the only way to convince people that mmap is not such a big win. :-( Hmm... Maybe I'll even turn-out to be wrong. ;-) I really believe mmap falls into the category of "might be nice, but not necessary and does complicate things..." -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote: > > > > DES tells me he has a new version (0.10) which mmap()s. It supposedly > cuts the run time down significantly, I do not have the numbers in front > of me. I do. Still far too slow. I'll work on this tomorrow, since that seems the only way to convince people that mmap is not such a big win. :-( Hmm... Maybe I'll even turn-out to be wrong. ;-) I really believe mmap falls into the category of "might be nice, but not necessary and does complicate things..." -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote: > > > > > > Sorry, but a simplistic analysis like that just won't cut for grep. > > > The algorithmic complexity is highly relevant here. Try this: > > > > Algorithmic complexity!?! > > Yup. I'm sorry. I've read your message and have decided that you're wrong. Outside of the regexp library, algorithmic complexity is not a factor here. It would take a beanbag to write anything other than an O(N) algorithm. The proposed grep is slow, very slow, and I've sent a long message to James outlining how to make it much faster, but algorithmic complexity is not an issue. > Also, fgetln() will copy the line buffer from time to time, though > that's not a simple computation, and probably of little fgetln() does a complete copy of the line buffer whenever an excessively long line is found. On this point, it's hard to do better without using mmap(), but mmap() has its own disadvantages. My last suggestion to James was to assume a worst case for long lines and mark the worst worst case with an XXX "this is unfortunate". > > The test you suggested doesn't show anything about that algorithmic > > complexity, though. > > Yeah? Try to back that with the results of the tests I suggested. No, it's not even worth my time. Now look. You've gotten me so upset I actually went and did a simple test. The test showed I'm right and you're wrong. Catting X number of copies of /etc/termcap into longfile causes the time grep uses to pass longfile searching for all occurrences of "printer" causes it to use an extra 0.03 seconds for every repetition of /etc/termcap in longfile. Gee, linear complexity wrt to file length. Who could've guessed!? What'ya bet GNU grep also exhibits linear complexity? :) Admit it, you jumped in with some bullshit about complexity when had you taken the time to look into what James meant when he said "it now spends 50% of its time in procline()" you would have kept quiet, realizing that he was talking about a constant factor in the complexity analysis, an subject where comments such as "it now spends 50% of its time in procline()" are relevent. :-) [Never mind that it should be spending near 100% of its time in procline...that just means he's still got work to do... :-] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote: > > > > > > Sorry, but a simplistic analysis like that just won't cut for grep. > > > The algorithmic complexity is highly relevant here. Try this: > > > > Algorithmic complexity!?! > > Yup. I'm sorry. I've read your message and have decided that you're wrong. Outside of the regexp library, algorithmic complexity is not a factor here. It would take a beanbag to write anything other than an O(N) algorithm. The proposed grep is slow, very slow, and I've sent a long message to James outlining how to make it much faster, but algorithmic complexity is not an issue. > Also, fgetln() will copy the line buffer from time to time, though > that's not a simple computation, and probably of little fgetln() does a complete copy of the line buffer whenever an excessively long line is found. On this point, it's hard to do better without using mmap(), but mmap() has its own disadvantages. My last suggestion to James was to assume a worst case for long lines and mark the worst worst case with an XXX "this is unfortunate". > > The test you suggested doesn't show anything about that algorithmic > > complexity, though. > > Yeah? Try to back that with the results of the tests I suggested. No, it's not even worth my time. Now look. You've gotten me so upset I actually went and did a simple test. The test showed I'm right and you're wrong. Catting X number of copies of /etc/termcap into longfile causes the time grep uses to pass longfile searching for all occurrences of "printer" causes it to use an extra 0.03 seconds for every repetition of /etc/termcap in longfile. Gee, linear complexity wrt to file length. Who could've guessed!? What'ya bet GNU grep also exhibits linear complexity? :) Admit it, you jumped in with some bullshit about complexity when had you taken the time to look into what James meant when he said "it now spends 50% of its time in procline()" you would have kept quiet, realizing that he was talking about a constant factor in the complexity analysis, an subject where comments such as "it now spends 50% of its time in procline()" are relevent. :-) [Never mind that it should be spending near 100% of its time in procline...that just means he's still got work to do... :-] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote: > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? Nate, you know damn well that's not true. You're complaining about three lines in a large patch. Further, those three lines of the patch fix excessively long (+80 char) lines. Yes, you're right that those are non-functional changes and that ideally non-functional changes are placed in separate commits. You've also been around long enough to know that you're right and to be able to say so with an air of authority without a sense of insecurity, ending any debate about it after a mere 2 or 3 curt exchanges. Further, your communication skills should be sufficiently advanced to have noticed what appears (to me, at least) to have been the subtle miscommunication that occurred between message-id <199907282000.oaa02...@mt.sri.com> and message-id which lead to the stupid place you two are now sitting in. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote: > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. It's white! No, dammit, it's beige! Fuck you, I said it's white! Beige! White! I dunno, I guess for some people the distinction's actually meaningful, but for myself, I was never good with colours. Colours and such aside, I will have to explain the word "politic" to Brian, someday, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote: > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: Algorithmic complexity!?! It's a freaking grep application. There is no freaking algorithmic complexity. At least not outside of our regex library, anyways. The test you suggested doesn't show anything about that algorithmic complexity, though. If we have a slow regex library, though, I would consider that a separate problem from a slow grep. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote: > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? Nate, you know damn well that's not true. You're complaining about three lines in a large patch. Further, those three lines of the patch fix excessively long (+80 char) lines. Yes, you're right that those are non-functional changes and that ideally non-functional changes are placed in separate commits. You've also been around long enough to know that you're right and to be able to say so with an air of authority without a sense of insecurity, ending any debate about it after a mere 2 or 3 curt exchanges. Further, your communication skills should be sufficiently advanced to have noticed what appears (to me, at least) to have been the subtle miscommunication that occurred between message-id <[EMAIL PROTECTED]> and message-id <[EMAIL PROTECTED]> which lead to the stupid place you two are now sitting in. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote: > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. It's white! No, dammit, it's beige! Fuck you, I said it's white! Beige! White! I dunno, I guess for some people the distinction's actually meaningful, but for myself, I was never good with colours. Colours and such aside, I will have to explain the word "politic" to Brian, someday, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote: > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: Algorithmic complexity!?! It's a freaking grep application. There is no freaking algorithmic complexity. At least not outside of our regex library, anyways. The test you suggested doesn't show anything about that algorithmic complexity, though. If we have a slow regex library, though, I would consider that a separate problem from a slow grep. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote: > > > There seems to be at least one dependency on GNU grep in > > /ports/Mk/bsd.port.mk where the -F argument is used. > > -F is implemented. I saw that, but had assumed the semantics were different. I should have read the read the manpages more closely: they're not. Sorry. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote: > > > There seems to be at least one dependency on GNU grep in > > /ports/Mk/bsd.port.mk where the -F argument is used. > > -F is implemented. I saw that, but had assumed the semantics were different. I should have read the read the manpages more closely: they're not. Sorry. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Tue, Jul 27, 1999 at 10:32:40AM -0700, Jordan K. Hubbard wrote: > > Just to clear up a misconception; this isn't actually a sysinstall > problem. This is a ports bug which Satoshi or somebody introduced > when they added a dependency on the XFree86 port very prematurely. It I can claim a bit of the responsibility. It was done after Sue Blake complained that there was no way to distinguish packages requiring X from those that didn't. I wrote some extended message discussing different types of dependencies, and then Satoshi wrote the change. However, my archives show I pointed-out the problem (with possible solutions) from the start. Perhaps I would have been more urgent if I'd forseen the future, but it's one of those things you look at and figure "ah, it's so Freaking obvious that someone will fix it". The change was made long before the release and there was plenty of time to fix any breakage. It was just never fixed. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Tue, Jul 27, 1999 at 10:32:40AM -0700, Jordan K. Hubbard wrote: > > Just to clear up a misconception; this isn't actually a sysinstall > problem. This is a ports bug which Satoshi or somebody introduced > when they added a dependency on the XFree86 port very prematurely. It I can claim a bit of the responsibility. It was done after Sue Blake complained that there was no way to distinguish packages requiring X from those that didn't. I wrote some extended message discussing different types of dependencies, and then Satoshi wrote the change. However, my archives show I pointed-out the problem (with possible solutions) from the start. Perhaps I would have been more urgent if I'd forseen the future, but it's one of those things you look at and figure "ah, it's so Freaking obvious that someone will fix it". The change was made long before the release and there was plenty of time to fix any breakage. It was just never fixed. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote: > > How's it compare in speed? [I'd test it myself, but see my private > email...] Okay, following-up on myself, and indirectly Sheldon, It does seem a little too slow. I'm not sure that this is because it doesn't use mmap. Supposedly the merged buffer/vm means mmap doesn't make as large a difference as it used to. On a file with 10+ lines, the speed difference is rather restrictive. Looking over the gprof output, I think its authors (or some other intrepid hacker) will find ways to speed it up. Only about 10% of the time is spend in procline(). There seems to be a lot of unnecessary strncpy() that could be _easily_ avoided if free() on util.c:130 was avoided, but I'll let the authors speak first. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote: > > How's it compare in speed? [I'd test it myself, but see my private > email...] Okay, following-up on myself, and indirectly Sheldon, It does seem a little too slow. I'm not sure that this is because it doesn't use mmap. Supposedly the merged buffer/vm means mmap doesn't make as large a difference as it used to. On a file with 10+ lines, the speed difference is rather restrictive. Looking over the gprof output, I think its authors (or some other intrepid hacker) will find ways to speed it up. Only about 10% of the time is spend in procline(). There seems to be a lot of unnecessary strncpy() that could be _easily_ avoided if free() on util.c:130 was avoided, but I'll let the authors speak first. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote: > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Have you run your systems with J-grep as a replacement for GNU grep for a while (making sure nothing breaks)? There seems to be at least one dependency on GNU grep in /ports/Mk/bsd.port.mk where the -F argument is used. How's it compare in speed? [I'd test it myself, but see my private email...] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote: > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Have you run your systems with J-grep as a replacement for GNU grep for a while (making sure nothing breaks)? There seems to be at least one dependency on GNU grep in /ports/Mk/bsd.port.mk where the -F argument is used. How's it compare in speed? [I'd test it myself, but see my private email...] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, Jul 27, 1999 at 12:08:10PM +0200, Sheldon Hearn wrote: > > strongly opposed to it, or because you don't have time? If it's the > latter, I'll do it. If the former, note that your commit message was Consider also adding owner:group support to -stable in order to provide the longest change-over period possible. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 10:41:24PM -0700, Doug wrote:
>
> the parts that they need. However right after 3.2-R came out there was a
> flurry of -questions mail about broken pkg dependencies because sysinstall
> wasn't properly registering the X install. If the port depending on the
> existence of /var/db/pkg/X* is actually an error I'll report what I find to
> the -ports list.
You need to specify "port, eg. /usr/ports/x/y" or "package".
I'd be surprised if you find any port that depends on /var/db/pkg/x.
It used to be that packages would depend on X, but Sheldon reminded me
(although I think it was accidental :-) that XFree86 was added to
PACKAGE_IGNORE_DEPENDS to prevent this.
Thus, only /usr/ports should depend on X. Few if any of these should be
looking through ${PKG_DBDIR} for information. No packages should
depend on X.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, Jul 27, 1999 at 12:08:10PM +0200, Sheldon Hearn wrote: > > strongly opposed to it, or because you don't have time? If it's the > latter, I'll do it. If the former, note that your commit message was Consider also adding owner:group support to -stable in order to provide the longest change-over period possible. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 10:41:24PM -0700, Doug wrote:
>
> the parts that they need. However right after 3.2-R came out there was a
> flurry of -questions mail about broken pkg dependencies because sysinstall
> wasn't properly registering the X install. If the port depending on the
> existence of /var/db/pkg/X* is actually an error I'll report what I find to
> the -ports list.
You need to specify "port, eg. /usr/ports/x/y" or "package".
I'd be surprised if you find any port that depends on /var/db/pkg/x.
It used to be that packages would depend on X, but Sheldon reminded me
(although I think it was accidental :-) that XFree86 was added to
PACKAGE_IGNORE_DEPENDS to prevent this.
Thus, only /usr/ports should depend on X. Few if any of these should be
looking through ${PKG_DBDIR} for information. No packages should
depend on X.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: > > and installed it the "hard" way, however I know I'm going to run into > trouble down the road when ports start looking for the X stuff in > /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: > > and installed it the "hard" way, however I know I'm going to run into > trouble down the road when ports start looking for the X stuff in > /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How much memory do we need to install?
On Mon, Jul 19, 1999 at 05:34:07PM +0930, Greg Lehey wrote: > AFAIK, the minimum memory for installation is still 5 MB, and the > problems people had with 8MB machines failing to install was a bug, > right? What's the current status? Some people have reported that they need up to 12MB to install. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How much memory do we need to install?
On Mon, Jul 19, 1999 at 05:34:07PM +0930, Greg Lehey wrote: > AFAIK, the minimum memory for installation is still 5 MB, and the > problems people had with 8MB machines failing to install was a bug, > right? What's the current status? Some people have reported that they need up to 12MB to install. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
On Sun, Jul 18, 1999 at 05:44:39PM -0600, Warner Losh wrote:
>
> True, but since some of what I'm doing is making sure that there are
> no security implications to some of the paths, doing that would be
> useless, since that wouldn't be what is checked into the system. We
> really don't need the ifdefs for solaris, cray, etc, do we?
#if defined(CRAY2) && defined(UNICOS5)
if (!linemode) {
[...]
}
#endif /* defined(CRAY2) && defined(UNICOS5) */
And around that, there should probably be a #ifdef LINEMODE to boot.
Please trash them. Especially the termio vs. termios ones.
It's not that I'm anti-portability, it's just that we very rarely
come-up with a usermode program that is worth exporting.
I like this one even better,
#if defined(LINEMODE) && defined(KLUDGELINEMODE)
[...]
if (lmodetype < KLUDGE_LINEMODE) {
lmodetype = KLUDGE_LINEMODE;
clientstat(TELOPT_LINEMODE, WILL, 0);
send_wont(TELOPT_SGA, 1);
} else if (lmodetype == NO_AUTOKLUDGE) {
lmodetype = KLUDGE_OK;
}
#endif /* defined(LINEMODE) && defined(KLUDGELINEMODE) */
[It looks like the stupid thing is a runtime option anyways, after the
#ifdefs...]
In the first 90% of sys_term.c, I'm not sure I could find more than a
couple sets of 25 contiguous lines that don't contain at least one #if
or #endif...
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
On Sun, Jul 18, 1999 at 05:44:39PM -0600, Warner Losh wrote:
>
> True, but since some of what I'm doing is making sure that there are
> no security implications to some of the paths, doing that would be
> useless, since that wouldn't be what is checked into the system. We
> really don't need the ifdefs for solaris, cray, etc, do we?
#if defined(CRAY2) && defined(UNICOS5)
if (!linemode) {
[...]
}
#endif /* defined(CRAY2) && defined(UNICOS5) */
And around that, there should probably be a #ifdef LINEMODE to boot.
Please trash them. Especially the termio vs. termios ones.
It's not that I'm anti-portability, it's just that we very rarely
come-up with a usermode program that is worth exporting.
I like this one even better,
#if defined(LINEMODE) && defined(KLUDGELINEMODE)
[...]
if (lmodetype < KLUDGE_LINEMODE) {
lmodetype = KLUDGE_LINEMODE;
clientstat(TELOPT_LINEMODE, WILL, 0);
send_wont(TELOPT_SGA, 1);
} else if (lmodetype == NO_AUTOKLUDGE) {
lmodetype = KLUDGE_OK;
}
#endif /* defined(LINEMODE) && defined(KLUDGELINEMODE) */
[It looks like the stupid thing is a runtime option anyways, after the
#ifdefs...]
In the first 90% of sys_term.c, I'm not sure I could find more than a
couple sets of 25 contiguous lines that don't contain at least one #if
or #endif...
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 04:18:08PM -0700, Mike Smith wrote: > > The only addition I'd want to make to > asprintf() is reasprintf() which reallocs and appends to the end of > an already existing string. And don't forget reasprintff() (a-la reallocf()). Ugh. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 06:28:52PM -0600, Warner Losh wrote: > > : Looking at OpenBSD's actual definition of strlcat() which returns the > : number of chars that would have been in the final string is > : potentially non-useful, but not really too terrible. > > No. It is useful. If you look at the return value, you can detect > that an overflow would have happened and bail w/o having the overflow No, they could simply return sizeof(buf) + 1 and have the same effect. Running through the whole length of the string that would have been created is potentially non-useful [sic]. It also potentially slows strlcat() down, particularly is some programmers start to rely on its behaviour to find the new amount of memory needed to allocate instead of doing the math themselves. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 11:20:04PM -0400, Bakul Shah wrote:
>
> That is, the returned ptr points in `dst' _just_ past the
> copied data. Note that `dst_end' points to the _last_ char
> of `dst'.
This sounds a lot like the GNU stpcpy() except that stpcpy() doesn't
take the middle argument dst_end (and therefore isn't as easy to make
secure).
Adding stpcpy() and pstpcpy() ("p", for pointer? I dunno...) wouldn't
bother me one iota.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 04:18:08PM -0700, Mike Smith wrote: > > The only addition I'd want to make to > asprintf() is reasprintf() which reallocs and appends to the end of > an already existing string. And don't forget reasprintff() (a-la reallocf()). Ugh. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 06:28:52PM -0600, Warner Losh wrote: > > : Looking at OpenBSD's actual definition of strlcat() which returns the > : number of chars that would have been in the final string is > : potentially non-useful, but not really too terrible. > > No. It is useful. If you look at the return value, you can detect > that an overflow would have happened and bail w/o having the overflow No, they could simply return sizeof(buf) + 1 and have the same effect. Running through the whole length of the string that would have been created is potentially non-useful [sic]. It also potentially slows strlcat() down, particularly is some programmers start to rely on its behaviour to find the new amount of memory needed to allocate instead of doing the math themselves. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Thu, Jul 15, 1999 at 11:20:04PM -0400, Bakul Shah wrote:
>
> That is, the returned ptr points in `dst' _just_ past the
> copied data. Note that `dst_end' points to the _last_ char
> of `dst'.
This sounds a lot like the GNU stpcpy() except that stpcpy() doesn't
take the middle argument dst_end (and therefore isn't as easy to make
secure).
Adding stpcpy() and pstpcpy() ("p", for pointer? I dunno...) wouldn't
bother me one iota.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote:
>
> If all you're saying is that you want an API that doesn't require a test
> against the known length of src (append in your example), then you won't
> like strl*. :-)
Well, if I read your message correctly, the difference between fooncat()
and strlcat() would be that strlcat() returns the total number of
chars in (or would be in) the destination string, whereas fooncat()
returns the total number of chars copied. The former, strlcat(),
avoids the problem I was noting.
Looking at OpenBSD's actual definition of strlcat() which returns the
number of chars that would have been in the final string is
potentially non-useful, but not really too terrible.
[If I'm using strlcat() in the first place, am I _really_ going to
care how many chars would have been copied? Maybe in legacy code,
but in anything newer...]
> You'd probably prefer the functions to return the number of bytes which
> they did not manage to {copy,append}, yes? Lazy bastard [1]. :-)
Hmm... That's an interesting idea...
> strl{cpy,cat}. And the original question was whether or not we'd add the
> strl{cpy,cat} functions to libc. If we do, I seriously hope I'll be
Ahh, well, you did hijack this off of the -security list. Adding
strlcpy() and strlcat() is probably a good idea.
> given the opportunity to submit a replacement manpage, since theirs
> sucks.
Bah. You're in avail now. Just commit ontop of whatever manpage gets
imported. ;-) If your replacement is good, no one will object. :)
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote:
>
> If all you're saying is that you want an API that doesn't require a test
> against the known length of src (append in your example), then you won't
> like strl*. :-)
Well, if I read your message correctly, the difference between fooncat()
and strlcat() would be that strlcat() returns the total number of
chars in (or would be in) the destination string, whereas fooncat()
returns the total number of chars copied. The former, strlcat(),
avoids the problem I was noting.
Looking at OpenBSD's actual definition of strlcat() which returns the
number of chars that would have been in the final string is
potentially non-useful, but not really too terrible.
[If I'm using strlcat() in the first place, am I _really_ going to
care how many chars would have been copied? Maybe in legacy code,
but in anything newer...]
> You'd probably prefer the functions to return the number of bytes which
> they did not manage to {copy,append}, yes? Lazy bastard [1]. :-)
Hmm... That's an interesting idea...
> strl{cpy,cat}. And the original question was whether or not we'd add the
> strl{cpy,cat} functions to libc. If we do, I seriously hope I'll be
Ahh, well, you did hijack this off of the -security list. Adding
strlcpy() and strlcat() is probably a good idea.
> given the opportunity to submit a replacement manpage, since theirs
> sucks.
Bah. You're in avail now. Just commit ontop of whatever manpage gets
imported. ;-) If your replacement is good, no one will object. :)
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
>
> As I understand it, the goal here is to return to the caller the number
> of bytes copied (however you represent it), so that the caller can
> easily determine whether or not dst is safe for operations demanding a
> null-terminated string.
[...]
> size_t
> fooncat(char *s, const char *append, size_t count)
>
> where the return value is the number of bytes {copied,appended}.
Eeks! This will quickly lead to code like
if (fooncat(string, append, sizeof(string)) != strlen(append))
...
which is rather evil, given that the second strlen(append) would be
completely gratuitous if it weren't for the interface you're
suggesting.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenBSD's strlcpy(3) and strlcat(3)
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
>
> As I understand it, the goal here is to return to the caller the number
> of bytes copied (however you represent it), so that the caller can
> easily determine whether or not dst is safe for operations demanding a
> null-terminated string.
[...]
> size_t
> fooncat(char *s, const char *append, size_t count)
>
> where the return value is the number of bytes {copied,appended}.
Eeks! This will quickly lead to code like
if (fooncat(string, append, sizeof(string)) != strlen(append))
...
which is rather evil, given that the second strlen(append) would be
completely gratuitous if it weren't for the interface you're
suggesting.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote: > > > > If you have a lot of users, all of which have buggy programs which eat > > a lot of memory, per-user swap quotas don't necessarily save your butt. > > The chance of these buggy programs running at the same time is not > exactly high... Well, it is higher than your probably giving credit for. Suppose Professor A. hands-out X assignment. Unfortunately, some piece of code he supplied to his, let's say 200 students ignorant first year students, has this particular memory-eating bug. Being ignorant first-year students, they will notice something is wrong, assume the problem is their fault, and repeat the exact same procedure five or so times. Again, being ignorant first year students, they will probably all be using the same shell server. To make things worse, some wise-ass may have told a bunch of them how to use ulimit or limit in order to push their available resources as high as possible (perhaps very high, since the admin hopefully recognizes that sometimes students need high resource limits to perform research). Fortunately, overcommit rescues the machine and kills those buggy programs instead of letting them spin around for ever in some kind of "malloc() failed ... must be temporary failure, wait and retry". -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote: > > > > If you have a lot of users, all of which have buggy programs which eat > > a lot of memory, per-user swap quotas don't necessarily save your butt. > > The chance of these buggy programs running at the same time is not > exactly high... Well, it is higher than your probably giving credit for. Suppose Professor A. hands-out X assignment. Unfortunately, some piece of code he supplied to his, let's say 200 students ignorant first year students, has this particular memory-eating bug. Being ignorant first-year students, they will notice something is wrong, assume the problem is their fault, and repeat the exact same procedure five or so times. Again, being ignorant first year students, they will probably all be using the same shell server. To make things worse, some wise-ass may have told a bunch of them how to use ulimit or limit in order to push their available resources as high as possible (perhaps very high, since the admin hopefully recognizes that sometimes students need high resource limits to perform research). Fortunately, overcommit rescues the machine and kills those buggy programs instead of letting them spin around for ever in some kind of "malloc() failed ... must be temporary failure, wait and retry". -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: > >So far, it seems the functionality is the same. A tarball > is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: > >So far, it seems the functionality is the same. A tarball > is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Searching the Handbook (was Re: 'rtfm script')
On Tue, Jul 06, 1999 at 11:55:26AM +0100, Nik Clayton wrote: > > *Much* simpler is to build a grep-alike that understands structured > documents, but that doesn't care how those documents are structured. This Perhaps dtags(1) a-la ctags(1). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Searching the Handbook (was Re: 'rtfm script')
On Tue, Jul 06, 1999 at 11:55:26AM +0100, Nik Clayton wrote: > > *Much* simpler is to build a grep-alike that understands structured > documents, but that doesn't care how those documents are structured. This Perhaps dtags(1) a-la ctags(1). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, Jul 06, 1999 at 02:52:08PM -0400, Brian F. Feldman wrote: > > On Tue, Jul 6, 1999, Brian F. Feldman wrote: > > > RTFM isn't a newby-apparent term. Name it help(1). > > > >That would cause problems with bash users. They already have > > a builtin help command. > > Which can be disabled in the bash port before the next release... Ugh. No. Objection on the grounds of "create more problems than it solves". We've already seen enough confusion from builtins such as time(1) having conflicting names. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, Jul 06, 1999 at 02:52:08PM -0400, Brian F. Feldman wrote: > > On Tue, Jul 6, 1999, Brian F. Feldman wrote: > > > RTFM isn't a newby-apparent term. Name it help(1). > > > >That would cause problems with bash users. They already have > > a builtin help command. > > Which can be disabled in the bash port before the next release... Ugh. No. Objection on the grounds of "create more problems than it solves". We've already seen enough confusion from builtins such as time(1) having conflicting names. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
On Sun, Jul 04, 1999 at 02:09:47PM +0200, Dag-Erling Smorgrav wrote: > > This should be trivial to translate to C. The only non-trivial part of > implementing this stuff is that you have to trick getopt() to make > - work. You'll have to put a : at the start of your getopt() > string and examine every argument getopt() complains about. Actually, the (FreeBSD) getopt(3) manpage includes at its end an example showing how to handle - options. This is preceeded by bold letters: "backwards compatibility only". HTH. HAND. :) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
On Sun, Jul 04, 1999 at 02:09:47PM +0200, Dag-Erling Smorgrav wrote: > > This should be trivial to translate to C. The only non-trivial part of > implementing this stuff is that you have to trick getopt() to make > - work. You'll have to put a : at the start of your getopt() > string and examine every argument getopt() complains about. Actually, the (FreeBSD) getopt(3) manpage includes at its end an example showing how to handle - options. This is preceeded by bold letters: "backwards compatibility only". HTH. HAND. :) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
