¹ã¸æÁª°î¸üпìµÝ http://www.gglb.com
1¡¢È«ÐÂÍƳö¡°Ãâ·Ñ·ÖÀà¹ã¸æ¡°À¸Ä¿ http://ad.gglb.com Äú¿ÉÒÔÔÚ´Ë·¢²¼ÄúµÄÒ»ÇÐ
ºÏ·¨ÐÅ¡£
2¡¢È«¹úΨһµÄ¡°¹ã¸æÈËÁÄÌìÊÒ¡±³ÏÑûÄúÔÚ´ËÇãÌý¹ã¸æÈ˵ÄÐÄÉù£¬½»Á÷¹ã¸æÈ˵ľ
Ñé¡£
3¡¢ÔÚ¡°¹ã¸æÂÛ̳¡±£¬Äã¿ÉÒÔÕÒµ½Ò»¸ö¹ã¸æÈËÕæÕý½»Á÷µÄ¿Õ¼ä¡£
David Schwartz wrote:
Well, we've heard various opinions and I think we can conclude that:
2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data
While on the topic: Who is working on devfs and why not?
I'd like to know whether there is some interest in getting that work
underway again. More than interested to help.
You're forgetting that devsw[] is another stopgap. The kernel should
probably use something like devfs, where dev_t's
In message pine.gso.3.95q.990605103111.15420k-100...@elect8, Nick Hibma
writes:
While on the topic: Who is working on devfs and why not?
I'd like to know whether there is some interest in getting that work
underway again. More than interested to help.
I'm not currently working on devfs, but I
While on the topic: Who is working on devfs and why not?
I'm not currently working on devfs, but I am building the infrastructure
it should be based on in the kernel.
Anymore information available on where you are with this?
Cheers,
Nick
To Unsubscribe: send mail to
i just would like to know about the state of SOFTUPDATES in -current
and in -stable (are there differences ?) for heavy load situations ...
is anyone here running SOFTUPDATES in such situations without trouble ?
i'm asking because i noticed some problems then high load benchmarking
a FreeBSD
In message pine.gso.3.95q.990605113837.15420q-100...@elect8, Nick Hibma
writes:
While on the topic: Who is working on devfs and why not?
I'm not currently working on devfs, but I am building the infrastructure
it should be based on in the kernel.
Anymore information available on where
Poul-Henning Kamp once stated:
=+tcp_keepalive=YES # Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
In message 199906051334.jaa12...@kot.ne.mediaone.net, Mikhail Teterin writes:
Poul-Henning Kamp once stated:
=+tcp_keepalive=YES # Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
After 8 attempts at reaching other end: Dead TCP connections.
--
Poul-Henning Kamp
=+tcp_keepalive=YES# Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
'inactive or dead' ?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Poul-Henning Kamp once stated:
==+tcp_keepalive=YES # Kill dead TCP connections (or NO).
=
=Mmm, probably dead TCP connections?
=
=After 8 attempts at reaching other end: Dead TCP connections.
Perhaps very probably dead? I'm just trying to prevent questions in
users' minds: why the
r4 and natd:
natd -dynamic -verbose -u -n ep1
In [UDP] [UDP] 192.168.1.5:127 - 192.168.1.31:125 aliased to
[UDP] 192.168.1.5:127 - 192.168.1.31:125
In [UDP] [UDP] 192.168.1.5:127 - 192.168.1.31:125 aliased to
[UDP] 192.168.1.5:127 - 192.168.1.31:125
In [UDP] [UDP]
David Schwartz wrote:
Well, we've heard various opinions and I think we can conclude that:
2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server
applications (web
servers, mail servers, etcetera) already have data
: There is no logical reason for a well-designed web server to enable
:keepalives. Of course, they don't hurt anything.
:
:...
:
: Agreed. Telnetd is the exception, keepalives are great for it. For
:everything else, almost, data timeouts make far more sense. And keepalives
:will do
Hello!
Where I can get info about all new features, introduced in FreeBSD 4? I've
heard about JAILING - virtual machines inside one physical host with own
root, etc. It is quite useful and I need this now :-) What about other new
features? Or point me to the source (except CVS tree :-) of
FWIW, I think only a fool would want a computer to NOT drop dead connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart does
NOT deserve to stay.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
Hi,
every small kde program i try to install (right now i tried Knewmail
and Kover) i get : checking for kde headers installed... configure:
error: your system is not able to compile a small KDE application!
Check, if you installed the KDE header files correctly. i'm using a
current machine
On Sat, 5 Jun 1999, Brett Taylor wrote:
I can only assume that we install our KDE headers somewhere different than
the developers (primarily on Linux machines). Dig around and figure out
where the headers are on the FreeBSD machines and then you'll have to
probably add a configure argument
Hi!
Since upgrading to the gtk-1.2 ports I've been having some problems with
programs compiled with it (like Gimp or e-conf)
If I run them as a regular user I get the following errors during startup
or during execution at random intervals (sometimes it takes longer than
other times..)
However
Quoting Daniel J. O'Connor (dar...@dons.net.au):
On 04-Jun-99 bush doctor wrote:
Pentium Pro MTRR support enabled, default memory type is uncacheable
What is MTRR? Using the web based cross referencing
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
In message pine.gso.3.95q.990605113837.15420q-100...@elect8, Nick Hibma
writes:
While on the topic: Who is working on devfs and why not?
I'm not currently working on devfs, but I am building the infrastructure
it should be based on
Basically I'm not working on devfs at the moment since the bit that made
it workable was ripped out with extreme prejudice by someone. I'm still
absolutly convinced that a dynamic device registration and export
framework is required in the long run, but I'm not fussed if it's based on
the current
I think part of the solution is a new class of keepalives..
With this new class, a keepalive is sent every N second (3600?)
but if no response is heard, no action is taken. The only action that is
taken is if a NAK is recieved in response.
Most IP addresses woudl be re-used within a few days, so
Increase traffic to your company's web site with a FREE Hyperlink to
IndustrySearch.Com. Thousands of industrial purchasing agents, buyers,
engineers and others searching for suppliers and services can locate
your business easily with our USA Industrial Directory.
You can visit
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart does
NOT deserve to stay.
If they are spaced too far apart, it
I just noticed (kernelworld from friday) that locate always cores
dump:
$ locate xxx
Segmentation fault (core dumped)
$ gdb -c locate.core /usr/bin/locate
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x804964b in ___tolower ()
#1 0x235000 in ?? ()
#2
On Sat, 5 Jun 1999, Garrett Wollman wrote:
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead
connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart
does
NOT
On Sun, 6 Jun 1999, Jean-Marc Zucconi wrote:
I just noticed (kernelworld from friday) that locate always cores
dump:
$ locate xxx
Segmentation fault (core dumped)
$ gdb -c locate.core /usr/bin/locate
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0
On Fri, Jun 04, 1999 at 10:21:05PM +0200, Matthew Dillon wrote:
Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.
In otherwords, nobody would notice. You wouldn't notice, the backbones
wouldn't notice... nobody would notice.
I would. I have
Garrett Wollman scribbled this message on Jun 5:
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead
connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart
does
On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote:
QED: The following patch.
[...]
+tcp_keepalive=YES # Kill dead TCP connections (or NO).
I still don't understand why you insist on making it YES by default. It
works fine like it is for most of the people right now.
So
On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
If they are spaced too far apart, it is possible for perfectly
legitimate connections to get shot down as a result of external
periodicities. (Does somebody's router reset every day at 2:45? If
so, better hope
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
One thing that no one points out is that this idle connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected later
I don't know what's worse; that Microsoft themselves can't keep
Windows running for 50 days, or that they're incapable of manually
bumping the counter to a value close to UINT_MAX and wait a few
minutes for it to roll over.
What's worst is probably that the bug doesn't affect operation.
The central issue of keepalives is that, for one machine, they don't create
a significant load. Multiplied by the number of machines on the Internet,
it can become a problem.
Divided by the combined bandwidth of the networks these machines are
using, it ceases to be a problem.
joelh
--
On 05-Jun-99 bush doctor wrote:
No man page yet. No horrors tho'. Man pages and info files are great,
but there's nothing like reading through the sources ... #;^)
Well given that the source contains help information its not a bad problem.. I
think the author is a tad busy at the moment :)
4. It would be desirable to have per socket timeouts, but would
require application changes which are unlikely to happen.
Huh? I was just considering writing the patch for this. What
application problems would this create?
The worst thing I can see is that it would mean that changing
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
One thing that no one points out is that this idle connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected later
I can only assume that we install our KDE headers somewhere different than
the developers (primarily on Linux machines).
By default, KDE installs to /usr/local/kde. On RedHat, the RPM
installs it to /opt/kde. All the includes are in
/usr/local/kde/include, the libs in /usr/local/kde/lib, etc.
I just noticed (kernelworld from friday) that locate always cores
dump:
$ locate xxx
Segmentation fault (core dumped)
The problem disappears if I recompile locate without the -DMMAP
option.
Running on the very latest current, it does not work for me.
By 'it', do you
On 6 Jun 1999, Joel Ray Holveck wrote:
By default, KDE installs to /usr/local/kde. On RedHat, the RPM
installs it to /opt/kde. All the includes are in
/usr/local/kde/include, the libs in /usr/local/kde/lib, etc.
Yup.
Most KDE programs, including the configure scripts, look for the
KDEDIR
41 matches
Mail list logo
