the semantics of FreeBSD rfork() have diverted far enough
from the original plan9 rfork() such that you can't consider it as the
same call. This makes life miserable for things like running Inferno on
FreeBSD.
--lyndon
___
freebsd-hackers@freebsd.org
of the
3B4K.
(We inflicted less upon ourselves :-)
Of course, this was just a little while after All Of Usenet hit 5MB per
day,
so I don't expect anyone to get this anecdote correct on their MCSE
exam :-)
--lyndon
___
[EMAIL PROTECTED] mailing list
http
:
cd /usr/ports; make install clean
should do it. Not that I recommend you actually try this ...
--lyndon
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
to this approach over using
command-line sendmail to submit: the client can make use of SMTP
facilities such as DSNs, message tracking, delivery-by, etc.
- --lyndon
-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com
iQA/AwUBPvdr1wqAE4lfBssoEQJxQgCfVD+371Qc
to date. Regardless, the CSRG code is a good starting
point for a lot of things. (For example, I'm currently about half way
through getting troff updated.)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
anything that does this.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
to say) and dump out what it thinks the parse tree looks
like. The problem isn't with the quotes being unbalanced, it's something
else that's making the shell ignore one (or more) of those quotes.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body
, you don't need the filesystem -- just treat
the raw disk as the file. By bypassing the filesystem you eliminate all
of its overhead. The INN documentation describes how to set this up. You
might want to try this before committing $$ to a netapp filer.
--lyndon
To Unsubscribe: send mail
will
be mandatory to implement.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
or write makefiles for gmake since
Sergey it's readily available on all the platforms.
Fine. We all adopt the Plan 9 mk and make Presotto the gatekeeper
of any further enhancements.
--lyndon (who doesn't understand why this is an issue, after having
just converted a *whole* lot
incompatible extensions to make (ours, GNUs, or anyone elses).
Writing portable makefiles is already enough of a pain in the ass.
--lyndon (death to feeping creaturism!)
(And yes, I would really miss the BSD/GNU if/then/else makefile
constructs if we went POSIX-anal on this.)
To Unsubscribe: send
Jos == Jos Backus [EMAIL PROTECTED] writes:
Writing portable makefiles is already enough of a pain in the
ass.
Jos Writing Makefiles is a pain, period.
Writing makefiles is easy. Writing *portable* makefiles is a pain.
There *is* a difference.
--lyndon
To Unsubscribe: send mail
the new features in a non-compatible way. The
import of tcsh on top of csh is a classic of this. What we have
works. It's not cool and/or sexy. But it works. If you *need* the
features of GNUmake, use GNUmake.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
there. Likewise for bind. The purgedir
function in /etc/rc (used to clean /var/run) will preserve the existing
directory structure under /var/run, so the sub-directory tree will
survive reboots.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body
then advise them to install
the latest version.
This was discussed within the last few weeks across a couple of
mailing lists. I don't recall which specific lists, but you could
try digging through a NANOG archive.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers
I've been having problems with a machine locking up while running X11,
and the usual console break sequence doesn't work. Is there a way to
break to the kernel debugger from X11? Or am I stuck with wiring
up a serial port console?
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED
version of the license. For which
they took my money, and then sent me someone elses license 8-P
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Has anyone enumerated the hardware platforms that the spkr(4)
device works on? And for those platforms where it doesn't work,
are there suggestions for (and documentation on) alternative
interfaces?
--lyndon
What about all the people who hoarded tonnes of spam in their bunkers?
I hoard spam
/usr/local/bin/g* for the site to
decide? (And I'm not tied to that horribly long macro name, either.)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
that listens on AF_UNIX as
Jacques well.
As a more general solution I have an inetd that groks AF_UNIX. You
would have to add chroot/jail support to it, though, and some would
argue that that's making inetd a bit featureful.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED
I've put up my AF_UNIX patches for inetd at:
ftp://orthanc.ab.ca/lyndon/freebsd/inetd.AF_UNIX.patch
The indentation is really gross. I did most of the edits with emacs
using its default C style. I didn't want to run the source through
indent in case the whitespace diffs obscured the real bits
Matt == Matt Dillon [EMAIL PROTECTED] writes:
Matt But unix-domain sockets are
Matt extremely useful in all manner of applications
They're also anywhere from 10-400% faster than PF_INET for connections
to the localhost (it varies a lot between different UNIX
implementations).
--lyndon
A few months back I taught telnet about named sockets. We've found this
very useful for testing things like IPC channels in our software
(e.g. telnet /var/run/lmtp). I've put the (-STABLE) patches up at:
ftp://orthanc.ab.ca/lyndon/freebsd/telnet.AF_UNIX.patch
If someone with commit priv's
to do this
is to acknowledge those vendors in the hardware section of the
handbook, and encourage people to support them by buying thier
products.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
VM system should not be working around
applications that don't declare their data arena correctly.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
hance of being
wrong for for n processes with unique uids racing a non-atomic mkdir()
call over (say) NFS.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Another company to look at is Yottayotta (www.yottayotta.com).
They just announced their first products last November, and there
isn't much hard product info online yet. For the arena they're
targeting, though, 70TB would be an entry level system.
--lyndon
To Unsubscribe: send mail to [EMAIL
"Alan" == Alan Clegg [EMAIL PROTECTED] writes:
Alan Or is that a reason *NOT* to look at their product?
I'd buy the storage gear, but I think I'll pass on the album ;-)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
engineers working there.
Much of the crew comes from Myrias Research, who were doing some very
bleeding edge parallel computing work in the mid to late '80s. (Too
bleeding edge for the marketplace, unfortunately ...)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
in gigabit ethernet on the switch
and server. (Plus you get redundency from the multiple interfaces.)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Sorry, my brain's fried this afternoon.
u_int64_t mask = ~0 (n-1);/* mask for iftab index */
u_int64_t mask = n-1; /* mask for iftab index */
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
"Luigi" == Luigi Rizzo [EMAIL PROTECTED] writes:
Luigi isn't so for ASCII chars 128 as well ?
There are no ASCII characters 128.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
can't use a 1777 directory, since that lets others DOS your
ability to create a crontab (even though the rogue file they dropped in
wouldn't be run by a reassonable cron).
I like the idea, but please show us a working design.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
use. I've submitted that
version as a pair of pr's (one for the kernel, and one for pciconf).
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
the FWRITE test cannot/should not be moved down
into the 'case PCIOCWRITE' part of the switch? This would make both
PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which
seems to me to be saner behaviour).
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
Anyone out there have a set of data sheets for the above chips
that they could email me? It looks like all the info pertaining to
these has been pulled from the Cirrus web site (?!?).
Thanks,
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ha
aying dont just jack up
scanner MAXUSERS. Use the NMBCLUSTERS= instead. Because that
scanner is usually the variable you want increased not the other
scanner parameters MAXUSERS increases.
FWIW I run our NFS server with NMBCLUSTERS=1. It doesn't burn that
much additional memory.
mat things on the wire, I drew a complete blank.
http://www.cisco.com/warp/public/cc/techno/media/lan/ether/channel/prodlit/faste_an.htm
It's pretty simple -- just an XOR of the bottom two bits of the destination
MAC address to determine which interface in the bundle to send the packet
out.
--lyndon
To U
"rbg" == rbg [EMAIL PROTECTED] writes:
rbg How does this compare with Intel's Adaptive Load Balancing
rbg (ALB) ? -- I guess it's closer to Intel's Link Aggregation
Dunno, I'm not familiar with ALB.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers"
spare root to the real root whenever you make significant changes (new
kernel, password file updates, etc).
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
an fdopen()?
Is it that much work to add
if ((stream=fdopen(fd, mode)) == NULL)
err(...);
after a mkstemp call? If you use it that much you can define a function
in your application. There's no need to add a non-portable routine
to libc for this.
--lyndon
To Unsubscribe: send mail to [EMAIL
em so /tmp
always has a directory to point to.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
me CAN$249 retail at the corner computer store. (That's about
USD$160.)
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:The main problem is that sendmail
places all queue files (and there :are several for each
undelivered message) in one directory
Sendmail 8.10 addresses this by allowing for multiple queue directories.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
overcommit.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
overcommit.
--lyndon
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
And what I'm pretty sure the majority of the readers on this list want
is for those of you who really think it's necessary to do it yourselves.
What? Nobody who wants to disable the policy knows how to do it? Hmmm, I
wonder whether that's significant...
Sheldon, if you can't contribute
* need for a large chunk of memory does not make
me a runaway process, and therefore subject to death.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
d the like) if they want the long standing semantics
of malloc() to be preserved. If the current malloc() cannot behave in
the documented and expected manner it needs to be renamed, because
malloc() it most certainly isn't.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
the memory?
That represents the code that needs to be fixed. Breaking malloc()
is not a suitable response IMO.
As a data point, we routinely disable overcommit on our SGI machines
and it doesn't hurt us one bit. And we aren't allocating gigabytes
of swap space, either.
--lyndon
To Unsubscribe: send
having a reasonably intelligent malloc() that
tells the truth, and returns unused memory to the system? Overcommit
is for lazy programmers, plain and simple. At least the SGI documentation
about overcommit admits that (or at least, did at one time).
--lyndon
To Unsubscribe: send mail to majord
for a large chunk of memory does not make
me a runaway process, and therefore subject to death.
--lyndon
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
) if they want the long standing semantics
of malloc() to be preserved. If the current malloc() cannot behave in
the documented and expected manner it needs to be renamed, because
malloc() it most certainly isn't.
--lyndon
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers
It would make sense except that the last time someone tried, some people
complained that it made it too easy to sniff passwords etc.
And thus was born tcpshow.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
It would make sense except that the last time someone tried, some people
complained that it made it too easy to sniff passwords etc.
And thus was born tcpshow.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
56 matches
Mail list logo
