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
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
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
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
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
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
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
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.
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.
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
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
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
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.
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
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.
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
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
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.
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.
[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
[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
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
brea
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 ( +
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
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
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
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.
--
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
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
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.
--
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
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
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
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
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
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).
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).
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
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
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
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..
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$
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
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..
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$
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
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
warning type="Anything said here wrong is my fault, not DES's"
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
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
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
warning type=Anything said here wrong is my fault, not DES's
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-num work. You'll have to put a : at the start of your getopt()
string and examine
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
-num work. You'll have to put a : at the start of your getopt()
string and examine
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?
--
On Sat, Jul 03, 1999 at 01:26:30PM -0700, Janie Dykes wrote:
you make excellent points. For the most part, the novice/average
person, believes that hackers are malicious, destructive individuals. A
huge number of computer users are misled and misinformed about the true
definition of the
On Wed, Jun 30, 1999 at 09:01:03PM +0100, Nik Clayton wrote:
On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
I've come to understanding that lack of documentation is probably one of
the factors that keep the system healthy,
I've just spent five minutes trying to
On Wed, Jun 30, 1999 at 09:01:03PM +0100, Nik Clayton wrote:
On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
I've come to understanding that lack of documentation is probably one of
the factors that keep the system healthy,
I've just spent five minutes trying to
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote:
And they are going to scream like mad if there isn't any. But in the end
they start reading the code anyway, even if there is docu, because they
don't trust anything but their own eyes and brain.
ports system == really really large
[Cc: line trimmed dramatically]
On Tue, Jun 22, 1999 at 11:52:25PM -0700, Mike Smith wrote:
Given that I've just spent a very unhappy couple of weeks demonstrating
that this toy you're referring to outperforms us by a factor of
anything from 3 to 10 on a range of basic benchmarks, and has
On Mon, May 31, 1999 at 09:22:23PM +0700, Max Khon wrote:
It's hard to check out the port for an arbitrary version of program.
E.g.: try to check out port for samba 1.9.18p10
Well, samba was upgraded from 1.9.18p10 to 2.0.0 at Mon Jan 18 2:34:03
1999 UTC, so to checkout 1.9.18p10,
$ cvs co
On Tue, Jun 01, 1999 at 01:21:46AM +1000, Andrew Kenneth Milton wrote:
How about optionally tarring the 'files' and 'patches' subdirs
(into seperate tarfiles or as one tarfile) to be extracted when the port
is needed. This would make cvsupping ports 'harder' I would imagine,
Has anyone
On Tue, Jun 01, 1999 at 01:04:43AM -1430, Mark Newton wrote:
The bsd.ports.mk file would begin by checking for the existence of
/usr/ports/buildenv/category/application. If it doesn't exist,
go looking for it in /cdrom, or on ftp.freebsd.org. If it does
The portcheckout script can easily
94 matches
Mail list logo
