�����������¿���
¹ã¸æÁª°î¸üпìµÝ http://www.gglb.com 1¡¢È«ÐÂÍƳö¡°Ãâ·Ñ·ÖÀà¹ã¸æ¡°À¸Ä¿ http://ad.gglb.com Äú¿ÉÒÔÔÚ´Ë·¢²¼ÄúµÄÒ»ÇÐ ºÏ·¨ÐÅ¡£ 2¡¢È«¹úΨһµÄ¡°¹ã¸æÈËÁÄÌìÊÒ¡±³ÏÑûÄúÔÚ´ËÇãÌý¹ã¸æÈ˵ÄÐÄÉù£¬½»Á÷¹ã¸æÈ˵ľ Ñé¡£ 3¡¢ÔÚ¡°¹ã¸æÂÛ̳¡±£¬Äã¿ÉÒÔÕÒµ½Ò»¸ö¹ã¸æÈËÕæÕý½»Á÷µÄ¿Õ¼ä¡£ 4¡¢¹ã¸æÁª°îÊÕ¼ÁËÈ«¹úÖøÃûµÄ¹ã¸æ¹«Ë¾£¬¹ã¸æ²ÄÁϹ«Ë¾£¬¹ã¸æÉ豸¹«Ë¾£¬²éѯ¸ü¿ì ½Ý£¬Ôö¼Ó¸ü·½±ã¡£ 5¡¢×îйúÄÚ¹ã¸æÐÂÎÅ£¬¹ã¸æ¶¯Ì¬¡£ 6¡¢È«ÐÂÍƳöÆ»¹ûÈí¼þ´óÔùËÍ£º¶àÖÖÉè¼Æ¡¢Í¼ÐÎÈí¼þÎÞÏÞÖƸßËÙÏÂÔØ¡£ 7¡¢´óÁ¿¹úÄÚÓÅÐã¹ã¸æͼ¿â£¬½ÔΪȫ¹ú¸÷µØµÄ»§Íâ¹ã¸æͼÐΣ¬Ô°æÔùËÍ£¬Ï£ÍûÄܸøÄú ´øÀ´Áé¸Ð¡£ À´¹ã¸æÁª°î£¬×öÁª°î¹ã¸æ http://www.gglb.com ¹ã¸æÁª°îÏÂÔØÕ¾µã£º http://download.gglb.com ×îÖØÒªµÄÒ»µã£¬ÄúÔÚ¡°¹ã¸æÁª°î¡±Ëù×öµÄÒ»ÇУ¬¶¼ÊÇÃâ·ÑµÄ¡£ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 timeouts, which makes keepalives redundant. Huh? The keepalive option *is* a kind of data timeout.. It's a failsafe so that if nothing has been heard for a while then it explicitly does a check to see if the network connection is still valid. Of course a server app is free to implement it's own data timeouts, but it shouldn't have to reinvent what the kernel can do very well already and is very difficult to do in userland. There are several sorts of timeouts that server apps *may* want: - Some sort of upper bound on a session time, eg: a fingerd session may not last more than 1 hour, regardless of whether it's doing something. Something like a http server might put an upper limit of something like 24 hours - if it is too small and it will interfere with large downloads. - Some sort of idle timeout, eg: a smtp server may want to time out after 10 minutes of not recieving a command. - A way of detecting a stalled or rebooted client. This is what keepalive does. It lets you detect a lost connection before some other longer timeout (eg: 24 hours) kicks in. In my opinion, in the vast majority of cases, data timeouts are more logical than keepalives. 'telnetd' being the most obvious exception. Telnetd is the worst example. Just because I have not typed something for two hours is no indication that the session should be closed. Only the kernel can test the validity of the network link in this case. However, of I drop a link or reboot, then I do want it cleaned up in a timely fashion. DS Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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 only exist for devices that actually exist. xxx_init() is far too early to decide which hardware devices exist. Bruce Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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 am building the infrastructure it should be based on in the kernel. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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...@freebsd.org with unsubscribe freebsd-current in the body of the message
SOFTUPDATES stability
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 machine with SOFTUPDATES enabled (ended up in an unusable filesystem) - but i'm not shure if it was due to the SOFTUPDATES or maybe due to other kernel options or the ata driver (but i did not use busmastering ...) so it would be nice if someone could post here or mail me some experiences with SOFTUPDATES in production environments (yes i know its labeled alpha :-) t -- graic...@innominate.de innominate GmbH networking people fon: +49.30.308806-13 fax: -77web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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 you are with this?
I currently have a kernel running where dev_t is a pointer to a
struct dev and where char and block devs are collapsed at the
dev_t level. There are some bogons i need to fumigate, but I'm
off to give a course in Stockholm much of this coming week, so
don't expect any commits just now. (I may actually postpone/abandon
this step for now, since some of the changes pulls rugs away which
cover what looks to me like holes in the floor).
Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
code.
When I have that bit down and done, the next step is for device
drivers to register individual dev_t's rather than blanket cdevsw
entries. The later ability will be retained for pseudo drivers
and other (pseudo)magic.
This registration will look pretty much like the current #ifdef'ed
DEVFS stuff, and in addition it will allow the driver to hang two
fields of the dev_t, typically a pointer to the struct softc and
maybe a unit number or something. This will obsolete all of
the magic minor - {unit|softc} converters in our drivers and
make the NFOO configuration obsolete.
That is, as such the end of this little project, and where a future
DEVFS could take off from. Basically all that is needed for a DEVFS
to do, is to hook into the dev_t maintenance code and construct
the directory tree.
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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
Re: net.inet.tcp.always_keepalive on as default ?
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 FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
=+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
Re: net.inet.tcp.always_keepalive on as default ?
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 heck could anyone want to set this to NO? If there is a hint some of this connections _may_ really be alive... May be a pointer to a more detailed explanation should go into the rc.conf's comment? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
natd problem
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] 192.168.1.6:138 - 192.168.1.31:138 aliased to [UDP] 192.168.1.6:138 - 192.168.1.31:138 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 ep1 has IP 195.168.78.186, ep0 192.168.1.1 -- Tomas TPS Ulej System Administrator t...@internet.sk, tu36-ripe TELENOR Internet, NETLAB Network, Slovakia To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 timeouts, which makes keepalives redundant. Huh? The keepalive option *is* a kind of data timeout.. It's a failsafe so that if nothing has been heard for a while then it explicitly does a check to see if the network connection is still valid. Of course a server app is free to implement it's own data timeouts, but it shouldn't have to reinvent what the kernel can do very well already and is very difficult to do in userland. It's trivial to do in userland, just wrap your read in a select. If the select times out, bail. In many cases, the one-size-fits-all approach of keepalives doesn't fit. Why should someone be allowed to stay connected to my web server for _two_hours_ without sending one byte of data? There are several sorts of timeouts that server apps *may* want: - Some sort of upper bound on a session time, eg: a fingerd session may not last more than 1 hour, regardless of whether it's doing something. Something like a http server might put an upper limit of something like 24 hours - if it is too small and it will interfere with large downloads. Most web servers implement two different time outs. One is a 'request' timeout that typically is in the 2 to 5 minute range. Another is an output timeout that limits how long a connection can go without receiving at least a certain amount of data. Hard session limits are generally not useful -- after all, someone might put a 600Mb file up there and someone might want to retrieve it over a 28.8Kbps connection. Keepalives do not eliminate the need for _either_ timeout. Two hours is too long to wait for a request. Since the TCP connection may work even though the remote end's userland program is not receiving any data, the send timeout is still needed as well. There is no logical reason for a well-designed web server to enable keepalives. Of course, they don't hurt anything. - Some sort of idle timeout, eg: a smtp server may want to time out after 10 minutes of not recieving a command. - A way of detecting a stalled or rebooted client. This is what keepalive does. It lets you detect a lost connection before some other longer timeout (eg: 24 hours) kicks in. There are very few server applications where 24 hour timeouts make sense. In the vast majortity of cases (again, telnetd excepted), timeouts are in the 1-5 minute range. Even web servers sending data use timeouts less than 10 minutes. The timeout, though, is on the current block of data, not the whole file. In my opinion, in the vast majority of cases, data timeouts are more logical than keepalives. 'telnetd' being the most obvious exception. Telnetd is the worst example. Just because I have not typed something for two hours is no indication that the session should be closed. Only the kernel can test the validity of the network link in this case. However, of I drop a link or reboot, then I do want it cleaned up in a timely fashion. Agreed. Telnetd is the exception, keepalives are great for it. For everything else, almost, data timeouts make far more sense. And keepalives will do nothing, but won't hurt anything. As I have said before, any application that does not implement data timeouts for all states, and does not enable keepalives is BROKEN. DS To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
: 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 nothing, but won't hurt anything. : : As I have said before, any application that does not implement data :timeouts for all states, and does not enable keepalives is BROKEN. You are missing the point, big time. There are hundreds of programmers writing hundreds of servers, most written by third-parties. New ones pop up every day. Nobody is going to go through and make sure all of them turn on keepalives. Nobody is going to go and try to contact all the authors involved to try to get them to implement their own timeouts. There are, in fact, many servers where implementing a timeout is *inappropriate*. ssh, rsh, and telnet for example. nntp is an example of a server where the timeout depends on the use. Some ISP's might want to implement a timeout, others might not. At BEST I decided to *not* have a timeout... people can stay connected and idle for hours if they want. Your 'solution' is no solution at all. You aren't thinking through the problem carefully enough. The Keepalive capability exists for a reason. The original reasons for not turning them on by default all those years ago no longer exist, and the only reasons people come up with now are extremely shallow and uninformed. I have yet to hear a single informed opinion against turning on keepalives. All I hear is mob-mentality stuff: people with opinions not backed by real facts, or people with opinions based on assumptions that are incorrect. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
New 4's features
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 information. Thank you. -- doka To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
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 as if last night, installed kde from ports (yes, kde-libs was compiled with -CURRENT and EGCS) 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 like: --with_kde_includes= /some/dir/where/kde/includes/are Dig through the knewmail configure script at the top and look for an option like this. Brett *** Brett Taylorbr...@peloton.physics.montana.edu * br...@daemonnews.org * * http://www.daemonnews.org/* *** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
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 like: --with_kde_includes= /some/dir/where/kde/includes/are Dig through the knewmail configure script at the top and look for an option like this. Yes, for better or for worse (I'd vote for worse), the FreeBSD ports install the kde headers in /usr/local/include.. However a simple --prefix=/usr/local *should* fix any configure problems, and if this is to make it into a FreeBSD port, use --prefix=$(PREFIX). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Gtk trouble..
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 if I run them as root everything works perfectly. DUMP HERE devils% gimp Message: Passed serialization test IMLIB ERROR: SHM can't attach SHM Segment for Shared Pixmap mask Wrapper Falling back on Shared XImages Imlib ERROR: SHM can't attach SHM Segment for Shared XImage mask Falling back on XImages Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 2147 error_code 10 request_code 129 minor_code 1 aborting... gimp terminated: sigabrt caught Gdk-ERROR (recursed) **: BadShmSeg (invalid shared segment parameter) serial 2148 error_code 128 request_code 129 minor_code 5 aborting... gimp terminated: sigabrt caught END DUMP I also noticed that the shared memory blocks are not released after this crash so they tend to use up resources. BEGIN DUMP (gimp started without any previously assigned shm blocks) devils% ipcs Message Queues: T ID KEYMODE OWNERGROUP Shared Memory: T ID KEYMODE OWNERGROUP m 14090246 0 --rwarwarwa gabriel gabriel m 2424839 0 --rwarwarwa gabriel gabriel m 131080 0 --rwarwarwa gabriel gabriel Semaphores: T ID KEYMODE OWNERGROUP END DUMP My 4.0-CURRENT (Jun 3) kernel conf has the following SYSV options options SYSVSHM options SYSVMSG options SYSVSEM options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SHMMAXPGS=4097 (The SHMMAX options were added when trying to fix the problem, but weren't useful) ktrace shows the problem starting: BEGIN DUMP 12319 gimp CALL shmsys(0x3,0,0x40,0x3ff) 12319 gimp RET shmsys 2555913/0x270009 12319 gimp CALL shmsys(0,0x270009,0,0) 12319 gimp RET shmsys 805814272/0x3007c000 12319 gimp CALL shmsys(0x3,0,0x40,0x3ff) 12319 gimp RET shmsys 131083/0x2000b 12319 gimp CALL shmsys(0,0x2000b,0,0) 12319 gimp RET shmsys -1 errno 24 Too many open files 12319 gimp CALL write(0x2,0xbfbfcc10,0x49) 12319 gimp GIO fd 2 wrote 73 bytes IMLIB ERROR: SHM can't attach SHM Segment for Shared Pixmap mask Wrapp\ er 12319 gimp RET write 73/0x49 12319 gimp CALL write(0x2,0xbfbfcc08,0x2c) 12319 gimp GIO fd 2 wrote 44 bytes Falling back on Shared XImages END DUMP I tried playing around with the maxfiles in sysctl (kern.maxfiles and kern.maxfilesperproc) but to no effect :-\ I've sincerily run out of ideas :-( Can anyone help me fix this? Is this a limit problem?? How can I increase it? My full kernel conf file is at: http://www.maquina.com/pessoas/gabriel/DEVILS Thanks Jose Marcelino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What is MTRR all about???
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 tool I came up with MTRR's are a way to tell the processor how to cache regions of memory. Its commonly used to speed up video card access by disabling caching on the linear frame buffer, this makes writes to the card faster (around 0-30%). The penalty is that reading is slower, but since that doesn't happen very often the speed increase is good. Try man memcontrol - It doesn't yet work on SMP boxes though. Hmmm ... bantu.cl.msu.edu:dervish more /usr/src/usr.sbin/memcontrol/Makefile PROG= memcontrol NOMAN= yes .include bsd.prog.mk No man page yet. No horrors tho'. Man pages and info files are great, but there's nothing like reading through the sources ... #;^) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum #;^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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 in the kernel.
Anymore information available on where you are with this?
I currently have a kernel running where dev_t is a pointer to a
struct dev and where char and block devs are collapsed at the
dev_t level. There are some bogons i need to fumigate, but I'm
off to give a course in Stockholm much of this coming week, so
don't expect any commits just now. (I may actually postpone/abandon
this step for now, since some of the changes pulls rugs away which
cover what looks to me like holes in the floor).
Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
code.
When I have that bit down and done, the next step is for device
drivers to register individual dev_t's rather than blanket cdevsw
entries. The later ability will be retained for pseudo drivers
and other (pseudo)magic.
This registration will look pretty much like the current #ifdef'ed
DEVFS stuff, and in addition it will allow the driver to hang two
fields of the dev_t, typically a pointer to the struct softc and
maybe a unit number or something. This will obsolete all of
the magic minor - {unit|softc} converters in our drivers and
make the NFOO configuration obsolete.
That is, as such the end of this little project, and where a future
DEVFS could take off from. Basically all that is needed for a DEVFS
to do, is to hook into the dev_t maintenance code and construct
the directory tree.
DEVFS has always meant to do exactly this.
there is already a place in the structure for these two fields,
and when devfs is running, the devsw[] table is not consulted.
The vnode already contains a direct pointer to the devsw entry and a
cookie (minor number), and these are called directly.
there is already a node type for the 'unified' device type.
there are three types of device in devfs
BDEV, CDEV and DDEV.
DDEV has only a pointer to teh methods and a cookie. (as you suggest
above)
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
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 devfs or an successor. I'd feel a bit happier about spending more time on it If I had any thought that the result would not be ripped out by the throat as soon as it works again, by a maniac that doesn't understand that it's a working subsystem (it was fully working at the time it was vandaliased but the nice fellow didn't even try it, and I got no warning except the commit message). There were two known problems that were based in other parts of the code (mfs and some vfs/module stuff) And the install software couldn't install with it. If PHK is working an a framework to make this easier, I'd love to get a white-paper on the topic because it's all unknown stuff at the moment. To get it going, you basically need to reverse the backout commits done by SOS a year ago. DEVSF itself works, but it needs a different disk subsystem to be able to represent dynamic disk partitions properly. julian On Sat, 5 Jun 1999, Nick Hibma wrote: 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...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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 even if someonen hangs up, in most cases SOMETHING will respond with a NACK withinthe next day or two. julian On Sat, 5 Jun 1999, Matthew Dillon wrote: : 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 nothing, but won't hurt anything. : : As I have said before, any application that does not implement data :timeouts for all states, and does not enable keepalives is BROKEN. You are missing the point, big time. There are hundreds of programmers writing hundreds of servers, most written by third-parties. New ones pop up every day. Nobody is going to go through and make sure all of them turn on keepalives. Nobody is going to go and try to contact all the authors involved to try to get them to implement their own timeouts. There are, in fact, many servers where implementing a timeout is *inappropriate*. ssh, rsh, and telnet for example. nntp is an example of a server where the timeout depends on the use. Some ISP's might want to implement a timeout, others might not. At BEST I decided to *not* have a timeout... people can stay connected and idle for hours if they want. Your 'solution' is no solution at all. You aren't thinking through the problem carefully enough. The Keepalive capability exists for a reason. The original reasons for not turning them on by default all those years ago no longer exist, and the only reasons people come up with now are extremely shallow and uninformed. I have yet to hear a single informed opinion against turning on keepalives. All I hear is mob-mentality stuff: people with opinions not backed by real facts, or people with opinions based on assumptions that are incorrect. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Link Your Web Site To IndustrySearch.Com
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 at http://industrysearch.com Link Your Web Site to our USA Industrial Directory Data Base today! Visit IndustrySearch.Com at http://industrysearch.com and click on Link Your Web Site Thank you, K. Prater USA INDUSTRIAL DATA BASE MANAGEMENT To be removed from our mailing list, please click Reply and type REMOVE in the subject field To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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 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!) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Mmap problem in -current?
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 0x8049166 in ___tolower () #3 0x8048f93 in ___tolower () #4 0x80489f5 in ___tolower () The problem disappears if I recompile locate without the -DMMAP option. Jean-Marc -- Jean-Marc ZucconiPGP Key: finger j...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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 deserve to stay. 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 the keepalive would keep trying for a certain amount of time, and this would be finely configureable. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Mmap problem in -current?
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 0x804964b in ___tolower () #1 0x235000 in ?? () #2 0x8049166 in ___tolower () #3 0x8048f93 in ___tolower () #4 0x80489f5 in ___tolower () The problem disappears if I recompile locate without the -DMMAP option. Jean-Marc Running on the very latest current, it does not work for me. -- Jean-Marc ZucconiPGP Key: finger j...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 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, it would ruin dial-on-demand for a lot of people, i think. CU, Sec -- The Feynman problem solving Algorithm 1) Write down the problem 2) Think real hard 3) Write down the answer To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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 NOT deserve to stay. 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!) yes, but are routers normally down for a couple hours?? if they are, you have other problems than worring about connections... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 why shouldn't the few servers which have problems without it, enable it? Make it a knob in rc.conf but off by default. As I understand it, It suffices if the server requests the keepalives. So if every FreeBSD-box has it on by default, I simply can not choose to have no keepalifes anymore, even if I turn them off locally. So this change is going to hurt somebody, somewhere. CU, Sec -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had now way to indicate successful termination of their C Programs. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
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 no keepalives are scheduled for then!) But remember that the idea is the keepalive would keep trying for a certain amount of time, and this would be finely configureable. 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. A fundamental principle of protocol design is that synchronization effects can arise totally unexpectedly, with dangerous consequences for the stability of the Internet as a whole. It is necessary to introduce some amount of randomness in order to break up this unintentional synchronization. Modern (post-Van Jacobson) TCP is not directly subject to this effect unless you do something stupid like cause TCP to send a packet like clockwork every X units of time! (TCP can still fall prey to self-synchronization in the applications running on top of it, which is one of the reasons why routers are strongly encouraged to implement a RED queueing discipline by default.) I would withdraw my objection if keepalives were fixed to use a random distribution over [t - t/2, t + t/2]. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 using the same IP and the TCP connection is restored because it was kept alive, this presents a whole new world of interesting exploits. It's non-trivial, but that doesn't stop people like Network Associates' Labs from publishing papers on the subject. It seems to me that the keepalive might improve the security situation in the case in addition to doing something about connections with unknown status. The poor sod in this situation deserves something untoward, IMNSHO. Protocols like ssh do send something periodically whereas telnet doesn't. Telnet is a well-known security problem. As others have pointed out, this is an endemic problem in applications generally speaking, where a long-term idle connection isn't treated as an exception or an an error. Your point on randomization is well taken and is generally what's taught in graduate Internet architecture related courses (ok, Lixia Zhang will drill this into your head here at UCLA, YMMV elsewhere.) Although a more conservative distibution would be [t-t/2, t + 2t]. :-) -scooter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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. Nobody I've talked to has ever seen a Windows 95 machine stay up for over a week or so, let alone a month. joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What is MTRR all about???
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 :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 the timeout value on a running system wouldn't affect already opened sockets. Even that may be changable by an external utility if I can think of a way to handle the locking in userland. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 using the same IP and the TCP connection is restored because it was kept alive, this presents a whole new world of interesting exploits. It's non-trivial, but that doesn't stop people like Network Associates' Labs from publishing papers on the subject. Keepalives are not particularly useful against connection hijacking, as far as I can tell, except perhaps that a keepalive packet may disclose the current TCP sequence number to the new assignee of a dynamic IP. (This, of course, presents an argument for the opposite stance.) As near as I can tell, you're saying that if a transient outage is restored, then after it's restored, an idle connection may be used by an intruder. How does the transient outage affect this? If the transient outage has the side effect of changing routing, then an attacker (or somebody else) is moving cables around, or a dynamic link with a dynamic IP is being changed. In the former case, then the long delay between keepalive packets should not make them a valid protection. (If it takes an attacker more than a week to move a cable, then may I suggest your attacker needs to refine his technique.) In the latter case, then the attacker who now holds the destination IP can respond to the keepalive packets masquerading as the legitimate recipient as easily as they can do any other work involved in hijacking your connection. If the outage did not cause a reconfiguration, then the attacker generally has no different access to your network than before, and no more means to hijack an open connection than before. I've got some whiskey in me right now, so I may be unclear on what you're saying. Am I missing something here? Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
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. where the headers are on the FreeBSD machines and then you'll have to probably add a configure argument like: --with_kde_includes= /some/dir/where/kde/includes/are 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, too, so I haven't tested it as /usr/local.) Yes, for better or for worse (I'd vote for worse), the FreeBSD ports install the kde headers in /usr/local/include.. However a simple --prefix=/usr/local *should* fix any configure problems, and if this is to make it into a FreeBSD port, use --prefix=$(PREFIX). --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. FWIW, I've found that using /usr/local/kde instead of /usr/local has, in my case, been most helpful. I don't advocate it for every tiny library, but for something as large and complex as KDE, it works well. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Mmap problem in -current?
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 mean that locate does not work, that the failure test does not work (ie, locate is fine for you), or that the workaround does not work? Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
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 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, too, so I haven't tested it as /usr/local.)
KDEDIR is depreciated.
--prefix specifies where it should install to. However, this app
needs to find some 3rd-party include files, so --prefix is not
appropriate.
Uh no. The prefix is also used by the configuration script to figure out
where the kdelibs were installed to. From configure:
ac_default_prefix=${KDEDIR:-/usr/local/kde}
[...]
includedir='${prefix}/include'
[...]
echo $ac_n checking for KDE... $ac_c 16
echo configure:4014: checking for KDE 5
if test ${prefix} != NONE; then
kde_includes=${prefix}/include
ac_kde_includes=$prefix/include
FWIW, I've found that using /usr/local/kde instead of /usr/local has,
in my case, been most helpful. I don't advocate it for every tiny
library, but for something as large and complex as KDE, it works well.
Yes, KDE scatters too many things too many places to really be a good fit
in /usr/local/kde. Plus putting it in its own directory makes for easy
removal and switching between versions of KDE.
- alex
I thought felt your touch
In my car, on my clutch
But I guess it's just someone who felt a lot like I remember you.
- Translator
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
