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'
In message , 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 am building the infrastructure
it should be
> >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 majord...@
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 machi
In message , 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 you are with this?
I currently have a
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-
> =+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:
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)
: 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 noth
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 this
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 mac
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 argumen
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 i
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 refe
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
> In message , 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 infor
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 e
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 IndustrySearch.Com
<
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 is possible for perfectly
legitimate connections to get shot down a
I just noticed (kernel&world 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:
> <
> 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,
On Sun, 6 Jun 1999, Jean-Marc Zucconi wrote:
> I just noticed (kernel&world 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)
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 hav
Garrett Wollman scribbled this message on Jun 5:
> <
> 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 ap
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.
<
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 no keepalives are scheduled for then!)
> But remember that the i
> 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 late
> 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.
No
> 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
--
J
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 t
>> 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 reconnect
>> 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, e
>> I just noticed (kernel&world 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 'i
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
> KD
:> 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 is possible for perfectly
:legitimate connections to get shot down as a
:>
:> 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 no keepalives are scheduled for then!)
:
:But remember that the idea is
>> Most KDE programs, including the configure scripts, look for the
>> KDEDIR environment variable. I believe that the correct thing to do
>> with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this
>> in /etc/profile and /etc/csh.cshrc here. (I have KDE in
>> /usr/local/kde here, to
:> wouldn't notice... nobody would notice.
:
:I would. I have several long-lived connections, with a few of them
:are sometimes unreachable for quote some time. I like that they survive,
:and would hate it, if some brain-dead default would ruin my perfectly
:set up connections.
:
:Even more, i
:<
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 no keepalives are scheduled for then!)
:
:> But remember th
:
:> 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 c
: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 righ
46 matches
Mail list logo
