Re: What's with NFS?
mergemaster is needed to update your /etc files. Vauge hints of this can be found in the updating file: 20010918: Peter has committed his new kthread nfs client/server code. NFS may be unstable after this date. 20010319: portmap had changed name to rpcbind for maximum POLA in your current world. /etc/hosts.{allow,deny} needs changes. nfs and other rpc based programs that rely on portmapper will not work without updates to /etc/hosts.{allow,deny} and /etc/netconfig. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mktime() doesn't fix deadzones...
I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Sean Chittenden msg37133/pgp0.pgp Description: PGP signature
Re: What's with NFS?
On Tuesday, 9 April 2002 at 22:56:33 -0700, Kris Kennaway wrote: On Tue, Apr 09, 2002 at 07:04:34PM +0930, Greg 'groggy' Lehey wrote: Since a recent upgrade to one of my development systems, I can't use nfsd. I've completely reinstalled /etc, set all appropriate knobs in rc.conf. rpcbind no longer gets started, and mountd dies with can't register messages for all services. This would seem reasonable except that there's no longer any reference to rpcbind in any configuration file, and starting rpcbind doesn't help. I'm stuck here. If anybody can tell me what's going on, I'd be grateful. # grep rpcbind rc.network echo -n ' rpcbind'; ${portmap_program:-/usr/sbin/rpcbind} \ *sigh* I was updating from the wrong tree. Sorry for the waste of bandwidth. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Current in Production
Howdy, I'd just like to thank the FreeBSD team for an outstanding job. I've got a FreeBSD-current system in production running an Intranet that has just exceeded one year's uptime. Admittedly, the snapshot I built was 30/10/2000, but it does go to show that current can indeed be used for production systems. The system only ever had one reboot and that was when the installation was migrated to a new box. For those that are interested, the Intranet uses Apache, PHP, Firebird and OpenLDAP for various Web-based management applications/tasks. Again, thanks to everyone responsible for providing a reliable and dependable distribution, even when it's considered unstable and for development purposes only. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: compiling the kernel (LINT) with icc, open problem
On 9 Apr, aaron wrote: Hmmm... BTW I would be very interested how icc compares to gcc32. Seems both have code to optimize for MMX, SSE, and the nice vector stuff in recent i386 processors. Feel free to send results. :-) This might not be such an issue with the kernel but I thouhgt it could benefit -lm :) Search for MessageId [EMAIL PROTECTED] in -current for the ICC part. Is there any ongoing effort to make the Makefiles gcc32-ready? I tried to compile the kernel with gcc32 but it failed. There's work in progress to include gcc32 as the base system compiler. Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libkern/quad.h
On Tue, Apr 09, 2002 at 04:58:42PM +0200, Alexander Leidinger wrote: quad.h contains: ---snip--- /* * XXX * Compensate for gcc 1 vs gcc 2. Gcc 1 defines ?sh?di3's second argument * as u_quad_t, while gcc 2 correctly uses int. Unfortunately, we still use * both compilers. */ #if __GNUC__ = 2 typedef unsigned intqshift_t; #else typedef u_quad_tqshift_t; #endif ---snip--- Is this still valid? Does someone really use gcc 1 to compile FreeBSD? I assume your question stems from trying to use icc. Please wrap this bit [semi]-properly with: #ifdef __GNUC__ #if __GNUC__ = 2 typedef unsigned intqshift_t; #else typedef u_quad_tqshift_t; #endif #endif You can then put a defintion for #ifdef __IC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libkern/quad.h
On Tue, 9 Apr 2002, Alexander Leidinger wrote: quad.h contains: ---snip--- /* * XXX * Compensate for gcc 1 vs gcc 2. Gcc 1 defines ?sh?di3's second argument * as u_quad_t, while gcc 2 correctly uses int. Unfortunately, we still use * both compilers. */ #if __GNUC__ = 2 typedef unsigned intqshift_t; #else typedef u_quad_tqshift_t; #endif ---snip--- Is this still valid? Does someone really use gcc 1 to compile FreeBSD? This became invalid before FreeBSD-2.0 was released. Most special cases to support gcc's before approx 2.7 are now bogus. Unlike the above, most of them are just for optimizations or for better diagnostics, so removing them shouldn't break compiling with old versions of gcc any more than not having the for other C compilers breaks compiling with other C compilers. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LOOKUP_SHARED is default now
On Tue, 09 Apr 2002 15:06:19 -0400, Jeff Roberson wrote: Right, sorry. There was some minimal discussion about this on arch quite a while ago. Basically, it allows namei to return leafs locked with shared locks instead of exclusive locks when a flag is set. This not only reduces contention, but also the number of exclusive locks that are floating around in the system. A good place for this to be documented is the NAMEI OPERATION FLAGS section of the namei(9) manual page. If you're not comfortable with the mdoc(7) markup language, you can submit your documentation change in plaintext format to the -doc list, and someone will usually do the markup and commit for you. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libkern/quad.h
On 10 Apr, Bruce Evans wrote: * XXX * Compensate for gcc 1 vs gcc 2. Gcc 1 defines ?sh?di3's second argument * as u_quad_t, while gcc 2 correctly uses int. Unfortunately, we still use * both compilers. Is this still valid? Does someone really use gcc 1 to compile FreeBSD? This became invalid before FreeBSD-2.0 was released. Most special cases to support gcc's before approx 2.7 are now bogus. Unlike the above, most of them are just for optimizations or for better diagnostics, so removing them shouldn't break compiling with old versions of gcc any more than not having the for other C compilers breaks compiling with other C compilers. Thank you, I will remove them in my icc patches. Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libkern/quad.h
On 10 Apr, David O'Brien wrote: On Tue, Apr 09, 2002 at 04:58:42PM +0200, Alexander Leidinger wrote: quad.h contains: ---snip--- /* * XXX * Compensate for gcc 1 vs gcc 2. Gcc 1 defines ?sh?di3's second argument * as u_quad_t, while gcc 2 correctly uses int. Unfortunately, we still use * both compilers. */ #if __GNUC__ = 2 typedef unsigned intqshift_t; #else typedef u_quad_tqshift_t; #endif ---snip--- Is this still valid? Does someone really use gcc 1 to compile FreeBSD? I assume your question stems from trying to use icc. Please wrap this bit [semi]-properly with: #ifdef __GNUC__ #if __GNUC__ = 2 typedef unsigned intqshift_t; #else typedef u_quad_tqshift_t; #endif #endif You can then put a defintion for #ifdef __IC Fullquote because your message seems to be truncated... Yes, your assumption is correct. And BDE already said this particular example became invalid before FreeBSD-2.0. I think it is ok to remove this particular example entirely and just use the first typedef. As for other occourences of the use of __GNUC__ without a check if it is defined: I will wrap them as soon as I review my own patches again. Bye, Alexander. P.S.: Any news on the icc - linux_base issue? -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mktime() doesn't fix deadzones...
Hi, I've cc'd -standards as I think this would be of interest there. IMHO the SQL code you quote in the PR should fail with an ``invalid time'' error. Personally I like the fact that mktime() returns -1 - it allows date's -v option to act sanely, although I must admit it was a PITA to get right. The really big question is, how can you ``fix'' mktime() ? If a value of 2002-4-7 2:0:0.0 becomes 2002-4-7 3:0:0.0 PDT, then you can deduce that 2 == 3 and go on to deduce other equally bizarre things Thinking about it makes my head hurt ! I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libkern/quad.h
On Wed, 10 Apr 2002, Alexander Leidinger wrote: As for other occourences of the use of __GNUC__ without a check if it is defined: I will wrap them as soon as I review my own patches again. Other occurrences are mostly correct. __GNUC__ is 0 in cpp expressions if it is used without it being defined. The problem with the ifdef in quad.h is that it defaults to the gcc-1 case if __GNUC__ is not = 2. The ifdef should have been written something like: #if __GNUC__ == 1 typedef u_quad_tqshift_t; #else typedef u_int qshift_t; #endif assuming that u_int really is correct for shift counts. (Shift counts can be of any integer type; it is just not useful to use a large type for them since shifting by an amount larger than the number of bits in the operand being shifted is undefined.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mktime() doesn't fix deadzones...
[please trim current from the CC list on reply] IMHO the SQL code you quote in the PR should fail with an ``invalid time'' error. There's some truth to that... but Apr 7th 2am -8:00 isn't an invalid datetime. It isn't correct, Apr 7th 3am -7:00 is the correct time, but they're identical because UNIX time never sees any of these kludgey timezone problems. Personally I like the fact that mktime() returns -1 - it allows date's -v option to act sanely, although I must admit it was a PITA to get right. I like that mktime() returns -1 for invalid times, but I don't think Apr 7th 2am-8 is an invalid time. Not correct, but not invalid either. The really big question is, how can you ``fix'' mktime() ? For now, tm-tm_hour += 1 is a reasonable solution, IMHO. From the testing done by the PostgreSQL folks, I gather that most other *NIX's automatically account for this border condition and change the passed in time structure. The alternative seems to me would be to have it return -1 on 2am and then leave it up to the application writer to detect this and attempt a 2nd call w/ tm-tm_hour incremented. The only caveat to that being that I'm not sure if all daylight savings shifts are 60min. Last thing to think about in favor of having mktime() handle this, October 40th automatically gets changed to November 9th already. Having mktime() adjust things for timezones as well as dates doesn't seem too unreasonable. If a value of 2002-4-7 2:0:0.0 becomes 2002-4-7 3:0:0.0 PDT, then you can deduce that 2 == 3 and go on to deduce other equally bizarre things Thinking about it makes my head hurt ! Sun Apr 07 02:00:00 PST 2002 = 1018173600 Sun Apr 07 03:00:00 PDT 2002 = 1018173600 That's a non-issue, I think you head is just going to have to continue to hurt. :~) -sc -- Sean Chittenden msg37144/pgp0.pgp Description: PGP signature
$B!*9-9p!*!!3FpJsDs6!$N$40FFb(B
$B!!FMA3$N%a!<%k$NG[?.?<$/$*OM$S?=$7>e$2$^$9!#(B $B!!$3$l$O(BWEB$B>e$K%"%I%l%9$r8x3+$5$l$F$$$kJ}$rBP>]$KG[?.$7$F$$$k9-9p(B $B!!%a!<%k$G$9!#:#8e0l@Z$N%a!<%kG[?.ITMW$NJ}$O$3$N%a!<%k$r$=$N$^$^(B $B!!$4JV?.$/$@$5$$!#(B $B!!7G<(HD$KEj9F$9$k$h$j8z2LE*$G$9!*(B $B!y!!#D#MMQ%a!<%k%"%I%l%9#1#0#0K|8D!!!y(B $B!!@kEA$N8z2LH472!*Bg9%I>!*%"%/%;%9?t$N>/$J$$7G<(HD$G$O!&!&!&(B $B!!9qFb$NEE;R%@%$%l%/%H%a!<%kMQ%a!<%k%"%I%l%9$,#1#0#0K|8D$"$j$^$9!#(B $B!!$3$l$+$i$N%S%8%M%9$K$OBgNL$N%a!<%k%"%I%l%9$r=jM-$9$k$3$H$OIT2D7g$G(B $B!!$"$k$H9M$($^$9!#(B $B!!$44uK>$G$"$l$P!"%F%-%9%H%U%!%$%k$G2<5-$K<($92A3J$G$*>y$jCW$7$^$9!#(B $B!!$*CMCJ$O!"0l8+>/!99b$$$+$H;W$o$l$k$+$b$7$l$^$;$s$,!"#D#M$rM9Aw$9$k(B $B!!$?$a$N@Zo$K=EMW$J(B $B!!$3$H$G$9!K!";HMQ$G$-$J$/$J$C$F$$$k$b$N$OB?>/$4$6$$$^$9!#$G$9$,!"$"(B $B!!$i$+$8$a$=$NITB-J,$r==J,9MN8$7$F3dA}$7$F$"$j$^$9$N$G$40B?42<$5$$!#(B $B!!%a!<%k%"%I%l%9$r$44uK>$NJ}$O!"7oL>!V%a%k%"%I4uK>!W$H%a!<%k2<$5$$!#(B $B!!$=$N:]!"$44uK>8D?t$H!"EvJ}$NF~6b3NG'MQ$N$?$a$KBe6b?69~;~$N(B $B!!?69~$_L>!J%+%?%+%J!K$r$*CN$i$;2<$5$$!#(B $B@^$jJV$7!"%a!<%k%"%I%l%9%j%9%H$rE:IU$7!"EvJ};XDj$NBe6b?69~@h$r(B $B!!$4O"MmCW$7$^$9!#(B $B!!>0!"E>Aw;~4VC;=L$N$?$a$K05=L%U%!%$%k!J<+8J2rE`J}<0$G%Q%9%o!<%IIU!K(B $B!!$G$*Aw$jCW$7$^$9!#(B $B2A3J0lMw!'(B 1$BK|7o!'(B 5,000$B1_(B 5$BK|7o!'(B10,000$B1_(B 10$BK|7o!'(B15,000$B1_(B 20$BK|7o!'(B20,000$B1_(B 50$BK|7o!'(B25,000$B1_(B 100$BK|7o!'(B30,000$B1_(B $B!!>0!"A4?t$*Gc$$5a$aD:$/J}$K$O!"%5!<%S%9$G%"%I%l%9<}=8%=%U%H$H(B $B!!%@%V$j:o=|%=%U%H$bL5NA$K$FDs6!$7$F$*$j$^$9!#(B $B!!$^$?$3$NB>$K!"(B $B!!!&7HBS%"%I%l%9%j%9%H!'(B10,000$B1_(B $B!!!JHsHV9f(B4$BK|7oJ,!K(B $B!&%M%C%H%o!<%+!Jm!'(B3,000$B1_(B $B!!!JETF;I\8)JL!'=;=j!\;aL>!\(BTEL$B!K(B $B!!!*N">pJs!'(B3,000$B1_(B $B!!!JpJs!'(B3,000$B1_(B $B!!!J%a%k%"%I!"K\L>!"=;=j!\(BTEL$B!"=P?H9;!"2CF~=!65CDBN!K(B $B!!$b$4$6$$$^$9$N$G!"$44uK>$NJ}$O$*Ld$$9g$o$;2<$5$$!#(B $B!!$*Ld9g$o$;@h!'!!%o%s%@!<%i%$%U!!([EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sftp troubles
[[EMAIL PROTECTED]]:/usr/home/lofi sftp [user]@[host] Connecting to [host]... [user]@[host]'s password: sftp get nonexistentfile Couldn't stat remote file: No such file or directory Segmentation fault (core dumped) --- snip Anyone else seeing this? Yesterday's current with base-system openssh. -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sftp troubles
On Wed, Apr 10, 2002 at 11:26:19PM +0200, Michael Nottebrock wrote: [[EMAIL PROTECTED]]:/usr/home/lofi sftp [user]@[host] Connecting to [host]... [user]@[host]'s password: sftp get nonexistentfile Couldn't stat remote file: No such file or directory Segmentation fault (core dumped) --- snip Anyone else seeing this? Yesterday's current with base-system openssh. i saw same error on FreeBSD 4.5-STABLE too. :( -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- zhuravlev alexander u l s t u n o c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LOOKUP_SHARED is default now
On Wed, Apr 10, 2002 at 12:00:13PM +0200, Sheldon Hearn wrote: A good place for this to be documented is the NAMEI OPERATION FLAGS section of the namei(9) manual page. I don't believe this option will exist long enought for it to need to be documented. Jeff changed the default, but left the option incase it unexpectedly caused problems for people. AFAIK, the option will totally go away RSN. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bug in m_split() ?
System Administrator wrote: Your message To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Bug in m_split() ? Sent:Wed, 10 Apr 2002 09:23:16 -0700 did not reach the following recipient(s): [EMAIL PROTECTED] on Wed, 10 Apr 2002 09:23:21 -0700 The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator. riffraff.plig.net #5.0.0 X-Postfix; unknown user: freebsd-current [EMAIL PROTECTED] on Wed, 10 Apr 2002 09:23:21 -0700 The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator. riffraff.plig.net #5.0.0 X-Postfix; unknown user: freebsd-hackers Reporting-MTA: dns; ex-sj-5.digisle.com Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 X-Supplementary-Info: riffraff.plig.net #5.0.0 X-Postfix; unknown user: freebsd-current X-Display-Name: [EMAIL PROTECTED] Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 X-Supplementary-Info: riffraff.plig.net #5.0.0 X-Postfix; unknown user: freebsd-hackers X-Display-Name: [EMAIL PROTECTED] Hackers, i'm sorry for the wide distribution, but can anyone, please, review the following patch to m_split() or at least comment on it. i have attached another example that shows my problem. --- uipc_mbuf.c.origMon Apr 8 14:40:23 2002 +++ uipc_mbuf.c Mon Apr 8 14:40:43 2002 @@ -584,6 +584,7 @@ if (remain MHLEN) { /* m can't be the lead packet */ MH_ALIGN(n, 0); + n-m_len = 0; n-m_next = m_split(m, len, wait); if (n-m_next == NULL) { (void) m_free(n); thanks, max ng_cow.c.gz Description: GNU Zip compressed data
rshd on 5.0-DP1
In giving the iso 5.0-DP1 a try I ran into the following. I have a clean and was wanting to create a simple trust between two systems using rsh and /.rhosts authentication (yea, i know rsh is bad but our silly software can run over ssh yet). So, I did the usual steps: created /root/.rhosts with an entry as follows: trustedhostname.mydomain.com root and of course chmod 600 /root/.rhosts uncommented the following line from /etc/inetd.conf shell stream tcp nowait root/usr/libexec/rshd rshd and fired up inetd: clienthost# inetd -wW I've done this a million times but on the 5.0-DP1 system, the following occurs: orrie@trustedhost sudo rsh clienthost echo foo rshd: Login incorrect. orrie@trustedhost As you can see, I get the error rshd: Login incorrect. I removed the /etc/hosts.allow so it is not a tcp wrapper issue and nothing is special in /etc/login.conf - it is a base install...no ports even. Now here is the odd thing. If I replace /usr/libexec/rshd with an rshd binary from a FreeBSD 4.5 box and make the following link (needed since a 4.5 rshd binary needs to link to it): ln -s /usr/lib/libc.so.5 /usr/lib/libc.so.4 The above sudo rsh clienthost echo foo command works fine. So, it seems like something with the 5.0-DP1 rshd. I didn't see anything special in the man page that changed rshd's functionality. Can someone point out where I'm being stupid? Orrie [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current in Production
Do you own a Harley? Do the Mosh Pit? You definitely like riding the edge of insanity... -current is always in a state of flux... I say you lucked out... FreeBSD is killer stuff, but, I personally wouldn't risk a job on the odds of getting a stable -current when I needed one... Chris Knight wrote: Howdy, I'd just like to thank the FreeBSD team for an outstanding job. I've got a FreeBSD-current system in production running an Intranet that has just exceeded one year's uptime. Admittedly, the snapshot I built was 30/10/2000, but it does go to show that current can indeed be used for production systems. The system only ever had one reboot and that was when the installation was migrated to a new box. For those that are interested, the Intranet uses Apache, PHP, Firebird and OpenLDAP for various Web-based management applications/tasks. Again, thanks to everyone responsible for providing a reliable and dependable distribution, even when it's considered unstable and for development purposes only. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Current in Production
Howdy, I would have lucked out if it wasn't reliable :-) If you do all the right things, such as follow the commit logs and test, test, test, you can get a snapshot of current that will prove reliable for a certain number of tasks. It had three months of testing before going into production, so I didn't get any rude shocks, nor was I risking my job. Everyone was aware of the potential for instability and the fallback was to run the apps on a 4.x release or stable. I needed proof by example that FreeBSD development code was just as capable - if not more - as commercial OS releases. I have that well and truly now :-) I liked riding the edge of insanity years ago. I've fallen over the edge since then :-) Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au -Original Message- From: Jim Bryant [mailto:[EMAIL PROTECTED]] Sent: Thursday, 11 April 2002 14:35 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Current in Production Do you own a Harley? Do the Mosh Pit? You definitely like riding the edge of insanity... -current is always in a state of flux... I say you lucked out... FreeBSD is killer stuff, but, I personally wouldn't risk a job on the odds of getting a stable -current when I needed one... Chris Knight wrote: [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message