From owner-freebsd-chat@FreeBSD.ORG Sun Jan 18 02:02:53 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08DB216A4CE for ; Sun, 18 Jan 2004 02:02:53 -0800 (PST) Received: from mail.uninterruptible.net (mail.uninterruptible.net [64.146.146.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 166AE43D31 for ; Sun, 18 Jan 2004 02:02:50 -0800 (PST) (envelope-from kris@catonic.net) Received: from Spaz.Catonic.NET (tnt6-216-180-4-136.dialup.hiwaay.net [216.180.4.136]) by mail.uninterruptible.net (Postfix) with ESMTP id D08FC5008A; Sun, 18 Jan 2004 10:03:13 +0000 (GMT) Received: by Spaz.Catonic.NET (Postfix, from userid 1002) id EF1713352; Sun, 18 Jan 2004 10:02:45 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by Spaz.Catonic.NET (Postfix) with ESMTP id EA7C14C6C; Sun, 18 Jan 2004 10:02:45 +0000 (GMT) Date: Sun, 18 Jan 2004 10:02:45 +0000 (GMT) From: Kris Kirby To: "Matthew D. Fuller" In-Reply-To: <20040116160124.GF41788@over-yonder.net> Message-ID: X-Mailer: !/bin/sh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: chat@freebsd.org Subject: Re: Good BSD/Linux Article (somewhat off-topic) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 10:02:53 -0000 On Fri, 16 Jan 2004, Matthew D. Fuller wrote: > Y'know, I posted it to -advocacy and my local LUG mailing list on > Tuesday, hoping maybe a couple people would read it and have some good > comments and suggestions on it. What happened is I haven't gotten > much of anything done the past few days, from using the comments and > suggestions, and answering all the emails I've gotten. Well written, Matthew. Good work. Sums it all up nicely. -- Kris Kirby, KE4AHR TGIFreeBSD IM: 'KrisBSD' "BIG BROTHER IS WATCHING YOU!" This message brought to you by the US Department of Homeland Security From owner-freebsd-chat@FreeBSD.ORG Tue Jan 20 00:02:17 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A9F316A4CE for ; Tue, 20 Jan 2004 00:02:17 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B5A43D1D for ; Tue, 20 Jan 2004 00:02:16 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 1B30E530A; Tue, 20 Jan 2004 09:02:14 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id C95705308; Tue, 20 Jan 2004 09:02:04 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 538D133C6A; Tue, 20 Jan 2004 09:02:04 +0100 (CET) To: "M. Warner Losh" References: <97988.1074541514@critter.freebsd.dk> <400C3FED.1010809@acm.org> <20040119.204745.91753144.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 20 Jan 2004 09:02:04 +0100 In-Reply-To: <20040119.204745.91753144.imp@bsdimp.com> (M. Warner Losh's message of "Mon, 19 Jan 2004 20:47:45 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 cc: chat@freebsd.org Subject: Re: October 2003 core monthly report X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 08:02:17 -0000 [digression from a discussion on -developers] "M. Warner Losh" writes: > I could say 'mergemaster needs cvs integration' but until the 'how' > element gets added, that's a nearly useless statement. /usr/ports/sysutils/etcmerge DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-chat@FreeBSD.ORG Tue Jan 20 10:49:50 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 225CA16A4CE for ; Tue, 20 Jan 2004 10:49:50 -0800 (PST) Received: from r0.zabco.net (r0.zabco.net [207.176.130.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52C6943D6A for ; Tue, 20 Jan 2004 10:45:28 -0800 (PST) (envelope-from bounce@alentus.com) Received: from ns52 (ns52.zabco.net [207.176.137.12]) by r0.zabco.net (8.11.6/8.11.3) with SMTP id i0KIjOS51311 for ; Tue, 20 Jan 2004 11:45:26 -0700 (MST) (envelope-from bounce@alentus.com) Message-ID: <439810571-220041220181443656@alentus.com> X-EM-Version: 6, 0, 1, 0 X-EM-Registration: #00B06306109813000D50 X-Sender: bounce@alentus.com X-MailPersonHistoryID: 529 X-MailPersonSubscriberID: 96232 X-MailPersonEmail: freebsd-chat@freebsd.org From: "SQL-Server-Performance.Com" To: "Joseph Mallett" Date: Tue, 20 Jan 2004 11:14:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: SQL-Server-Performance.Com Newsletter -- January 20, 2004 X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 18:49:50 -0000 ================================================================= **SQL-Server-Performance.Com Newsletter** ================================================================= January 20, 2004 ================================================================= Editor: Brad M. McGehee, MVP, MCSE+I, MCSD E-Mail: mailto:webmaster@sql-server-performance.com ================================================================= URL: http://www.sql-server-performance.com/ ================================================================= Information on how to subscribe, unsubscribe, and to change your e-mail address is at the bottom of this newsletter. This is a 100% opt-in newsletter. ================================================================= ================================================================= **Sponsor's Message** ================================================================= COMPARE AND SYNCHRONIZE SQL SERVER DATABASES Use Red Gate's tools for SQL Server databases for all your comparison and synchronization tasks. Tools include: --SQL Compare: Compare and synchronize database structures --SQL Data Compare: Compare and synchronize data in databases --DTS Compare: Compare SQL Server settings, jobs, logins and DTS packages --SQL Toolkit: Automate SQL Compare and SQL Data Compare Visit http://www.red-gate.com/sql/summary.htm for a FREE trial, or contact mailto:sales@red-gate.com ================================================================= ================================================================= **In This Issue** ================================================================= -- New Information Published on SQL-Server-Performance.Com -- New and Updated SQL Server Performance Tips -- Learn & Win: January Forum Contest With FREE Software ================================================================= ================================================================= **New Information Published on SQL-Server-Performance.Com** ================================================================= Here are some new items that were recently posted to SQL-Server-Performance.Com: --New for Writers: If you submit an article to SQL-Server- Performance.Com in 2004, and it is published, you will receive a free copy of LeadByte Software's Network Performance Suite, worth $977 --New Article: SQL Server Parallel Execution Plans If you haven't seen these yet, check them out at: http://www.sql-server-performance.com/ ================================================================= ================================================================= **Sponsor's Message** ================================================================= FREE White Paper on Data Recovery Best Practices -- by Stephen Wynkoop, MVP and Founder SSWUG Planning for data recovery is about more than just making sure your database is backed up. There are many things to consider. In his paper, veteran SQL Server guru Stephen Wynkoop discusses the best approaches to a solid data recovery solution. He outlines key planning points and investigates how select tools can help you accomplish a plan for success. This white paper is brought to you, compliments of Lumigent Technologies. Download it now at: http://www.lumigent.com/go/sd14 ================================================================= ================================================================= **SQL Server Performance Tuning and Optimization Tips** The SQL Server performance tips listed below were recently added or updated on the website. ================================================================= **Blocking** Blocking occurs when one connection to SQL Server locks one or more records, and a second connection to SQL Server requires a conflicting lock type on the record or records locked by the first connection. This causes the second connection to wait until the first connection releases its locks. By default, a connection will wait an unlimited amount of time for the blocking lock to go away. Blocking is not the same thing as a deadlock. A certain amount of blocking is normal and unavoidable. But too much blocking can cause connections (representing applications and user) to wait extensive periods of time, hurting overall SQL Server performance. In the worst cases, blocking can escalate as more and more connections are waiting for locks to be released, creating extreme slowdowns. The goal should be to reduce blocking as much as possible. Locks held by SELECT statements are only held as long as it takes to read the data, not the entire length of the transaction. On the other hand, locks held by INSERT, UPDATE, and DELETE statements are held until the entire transaction is complete. This is done in order to allow easy rollback of a transaction, if necessary. Some causes of excessive blocking, and ways to help avoid blocking, include: --Long-running queries. Anytime a query of any type, whether it is a SELECT, INSERT, UPDATE, or DELETE, takes more than a few seconds to complete, blocking is likely. The obvious solution to this is to keep transactions as short as possible. There are many tips on this website on how to help reduce transaction time, but some of them include: optimize Transact-SQL code; optimize indexes; break long transactions into multiple, smaller transactions; avoiding cursors, etc. --Canceling queries, but not rolling them back. If your application's code allows a running query to be cancelled, it is important that the code also roll back the transaction. If this doesn't happen, locks held by the query will not be released, which means blocking can occur. --Distributed client/server deadlock. No, this is not your typical deadlock that is handled automatically by SQL Server, but a very special situation that is not automatically resolved by SQL Server. Here's what can happen. Let's say that an application opens two connections to SQL Server. The application then asynchronously starts a transaction and sends a query through the first connection to SQL Server, waiting for results. The application then starts a second transaction and sends a query through the second connection to SQL Server, waiting for results. At some point, one of the queries from one of the connections will begin to return results, and the application will then begin to process them. As the application processes the results, at some point what could happen is that the remainder of the results become blocked by the query running from the other connection. In other words, the first query can't complete because it is being blocked by the second query. So in essence, this connection is blocked and cannot continue until the second query completes. But what happens is that the second query tries to return its results, but because the application is blocked (from the first query), its results cannot be processed. So this means that this query cannot complete, which means the block on the first query can never end, and a deadlock situation occurs. Neither connection will give up, so neither connection never ends, and the deadlock situation never ends. SQL Server is unable to resolve this type of deadlock, so unless you want to write applications that hang forever, you can take these steps to prevent this unusual situation: 1) Add a query time-out for each of the queries, or 2) Add a lock time-out for each of the queries, or 3) Use a bound connection for the application. In many ways, the best way to avoid blocking is to write well- tuned applications that follow the tuning advice found on this website. [7.0, 2000] ***** By default, blocking locks don't time out. The waiting connection waits until the lock is released, and the block is over. If you like, you can set a lock time-out so that a connection does not wait indefinitely for the blocking lock to be released. This is accomplished using the LOCK_TIMEOUT setting. When the LOCK_TIMEOUT setting is used to set a maximum amount of time that a connection can wait for a blocking lock to go away. This means that the connection that has the lock and is causing the blocking problem is not affected, but that the connection waiting for the block is halted, and receives an error message. When this happens, then error message 1222, "Lock request time- out period exceeded" is sent to the application. This means that the application needs to include the appropriate error-handling code to deal with this situation and take the appropriate action, which includes rolling back the transaction. If the application does not know how to deal with this error message, and the transaction is not rolled back, it is possible that the application can continue as if the transaction was not automatically cancelled. Because of this, you should not use the LOCK-TIMEOUT setting unless your application(s) that will be affected by it know what to do when they receive this message from SQL Server. The syntax for the SET LOCK_TIMEOUT is: SET LOCK_TIMEOUT timeout_period where timeout_period is the number of milliseconds that a connection waits for a blocking lock to go away before an error is returned from SQL Server to the application. A value of -1 is the default, which means to wait indefinitely. A value of 0 tells SQL Server not to wait at all, and to return the error immediately. This command is based on a per connection basis, and stays with the connection until the connection is broken, or a new SET LOCK_TIMEOUT command is issued. Updated [7.0, 2000] ***** Avoid INSERTing, UPDATEing, or DELETEing large numbers of records in a single transaction. If you do, all the records affected by your action will be locked until the transaction is done. If you find that you need to perform mass data changes, it is better to batch them into smaller, shorter transactions to prevent unnecessary locking. In addition, changing the backup method from full to simple will also reduce the overhead incurred by long running transactions. Once you are done with the long running activity, you can switch back to the full backup method. [6.5, 7.0, 2000] ***** One way to help identify blocking locks is to use Enterprise Manager. If you expand "Process Info" Under "Current Activity," for the appropriate server, and then scroll to the right of the screen, you will see if there are currently any blocking locks. If you do, you will see which SPID is blocking what other SPIDs. Unfortunately, this screen is not dynamically updated, so if you will want to refresh this screen often if you are looking for blocking locks. To refresh the screen, right-click on "Current Activity," not "Process Info," and then select "Refresh." Most blocking locks go away soon. But if a blocking lock does not go away, and it is prevent one or more users from performing necessary tasks, you can ask the user, whose SPID is causing the blocking, to exit their program that is causing the block. Or, you can KILL the blocking SPID from Enterprise Manager. KILLing the blocking SPID will cause the current transaction to rollback and allow the blocked SPIDs to continue. [7.0, 2000] ================================================================= **Sponsor's Message** ================================================================= IntelliVIEW -- Interactive Reporting Tool for SQL Server IntelliVIEW is an easy-to-use reporting solution that allows you to create rich & interactive reports from your SQL Server databases and integrate them into your applications. Design interactive reports with ease; integrate reporting into .NET, Java, and COM applications; analyze information in real-time; and make faster, better-informed decisions. Integrate Reporting into your SQL Server applications: --Create virtually any type of report--summary, cross-tabs, charts, etc. --Manipulate data using convenient drag & drop facilities. --Slash development time for creating reports by over 75%! --Publish reports easily across the web. --Export reports to popular formats like xls, pdf, rtf, etc. --Print Professional looking reports using the WYSIWYG printing features. --Absolutely No Client Licensing Fees! Download FREE client at http://www.intelliview.com/go/sqlperf ================================================================= **Cursors** Avoid using static/insensitive and keyset cursors, unless you have no other choice. This is because they cause a temporary table to be created in TEMPDB, which increases overhead and can cause resource contention issues. [6.5, 7.0, 2000] ***** If you have no choice but to use cursors in your application, try to locate the SQL Server tempdb database on its own physical device for best performance. This is because cursors use the tempdb for temporary storage of cursor data. The faster your disk array, the faster your cursor will be. [6.5, 7.0, 2000] ***** Using cursors can reduce concurrency and lead to unnecessary locking and blocking. To help avoid this, use the READ_ONLY cursor option if applicable, or if you need to perform updates, try to use the OPTIMISTIC cursor option to reduce locking. Try to avoid the SCROLL_LOCKS cursor option, which reduces concurrency. [6.5, 7.0, 2000] ***** When you are done using a cursor, don't just CLOSE it, you must also DEALLOCATE it. Deallocation is required to free up the SQL Server resources used by the cursor. If you only CLOSE the cursor, locks are freed, but SQL Server resources are not. If you don't DEALLOCATE your cursors, the resources used by the cursor will stay allocated, degrading the performance of your server until they are released. [6.5, 7.0, 2000] ***** If it is appropriate for your application, try to load the cursor as soon as possible by moving to the last row of the result set. This releases the share locks created when the cursor was built, freeing up SQL Server resources. [6.5, 7.0, 2000] ***** If you have to use a cursor because your application needs to manually scroll through records and update them, try to avoid client-side cursors, unless the number of rows is small or the data is static. If the number of rows is large, or the data is not static, consider using a server-side keyset cursor instead of a client-side cursor. Performance is usually boosted because of a reduction in network traffic between the client and the server. For optimum performance, you may have to try both types of cursors under realistic loads to determine which is best for your particular environment. [6.5, 7.0, 2000] ***** When using a server-side cursor, always try to fetch as small a result set as possible. This includes fetching only those rows and columns the client needs immediately. The smaller the cursor, no matter what type of server-side cursor it is, the fewer resources it will use, and performance will benefit. [6.5, 7.0, 2000] ================================================================= **Sponsor's Message** ================================================================= ELIMINATE SQL MAIL ACROSS YOUR ENTERPRISE IN 10 MINUTES OR LESS! Introducing SQL SENTRY, a powerful, agent-less system for SQL Server job and performance management that brings you unprecedented scheduling, monitoring, alerting and reporting: SCHEDULING: Intuitive, Outlook-style calendar view of your job schedules. With 10-minute, hour, 4-hr, day and week views, job conflicts are clearly highlighted and easily resolved. MONITORING: Link Windows performance counters directly to jobs and guard against failures before they occur by knowing how jobs are impacting server performance. ALERTING: SQL Sentry handles notifications for all job and server alerts, without agents. Alerting is centralized and SMTP-based, with no dependencies on SQL Mail or MAPI. REPORTING: 3-D runtime and performance charts provide unsurpassed analysis and resolution capabilities for job-related issues. For more information on SQL SENTRY, visit our website today: http://www.sqlSentry.net/ ================================================================= **Database Design** Bad logical database design results in bad physical database design, and generally results in poor database performance. So, if it is your responsibility to design a database from scratch, be sure you take the necessary time and effort to get the logical database design right. Once the logical design is right, then you also need to take the time to get the physical design right. Both the logical and physical design must be right before you can expect to get good performance out of your database. If the logical design is not right before you begin the development of your application, it is too late after the application has been implemented to fix it. No amount of fast, expensive hardware can fix the poor performance caused by poor logical database design. [6.5, 7.0, 2000] ***** Following standard database normalization recommendations when designing OLTP databases can greatly maximize a database's performance. Here's why: --Helps to reduce the total amount of redundant data in the database. The less data there is, the less work SQL Server has to perform, speeding its performance. --Helps to reduce the use of NULLS in the database. The use of NULLs in a database can greatly reduce database performance, especially in WHERE clauses. --Helps to reduce the number of columns in tables, which means that more rows can fit on a single data page, which helps to boost SQL Server read performance. --Help to reduce the amount of Transact-SQL code that needs to be written to deal with non-normalized data. The less code there is, the less that has to run, speeding your application's performance. --Helps to maximize the use of clustered indexes, the most powerful and useful type of index available to SQL Server. The more data is separated into multiple tables because of normalization, the more clustered indexes become available to help speed up data access. --Helps to reduce the total number of indexes in your database. The less columns tables have, the less need there is for multiple indexes to retrieve it. And the fewer indexes there are, the less negative is the performance effect of INSERTs, UPDATES, and DELETES. [6.5, 7.0, 2000] ***** If normalizing your OLTP database forces you to create queries with many multiple joins (4 or more), you may want to consider denormalizing some of the tables in order to reduce the number of required joins. Denormalization is the process of selectively taking normalized tables and re-combining the data in them in order to reduce the number of joins needed them to produce the necessary query results. Sometimes the addition of a single column of redundant data to a table from another table can reduce a 4-way join into a 2-way join, significantly boosting performance by reducing the time it takes to perform the join. While denormalization can boost join performance, it can also have negative effects. For example, by adding redundant data to tables, you risk the following problems: --More data means SQL Server has to read more data pages than otherwise needed, hurting performance. --Redundant data can lead to data anomalies and bad data. --In many cases, extra code will have to be written to keep redundant data in separate tables in synch, which adds to database overhead. As you consider whether to denormalize a database to speed joins, be sure you first consider if you have the proper indexes on the tables to be joined. It is possible that your join performance problem is more of a problem with a lack of appropriate indexes that it is of joining too many tables. Before you decide to denormalize a properly normalized database, be sure you thoroughly consider all of the implications and test performance both before and after you denormalize to see if your efforts have really bought you anything. [6.5, 7.0, 2000] ================================================================= **Sponsor's Message** ================================================================= ELIMINATE SQL MAIL ACROSS YOUR ENTERPRISE IN 10 MINUTES OR LESS! Introducing SQL SENTRY, a powerful, agent-less system for SQL Server job and performance management that brings you unprecedented scheduling, monitoring, alerting and reporting: SCHEDULING: Intuitive, Outlook-style calendar view of your job schedules. With 10-minute, hour, 4-hr, day and week views, job conflicts are clearly highlighted and easily resolved. MONITORING: Link Windows performance counters directly to jobs and guard against failures before they occur by knowing how jobs are impacting server performance. ALERTING: SQL Sentry handles notifications for all job and server alerts, without agents. Alerting is centralized and SMTP-based, with no dependencies on SQL Mail or MAPI. REPORTING: 3-D runtime and performance charts provide unsurpassed analysis and resolution capabilities for job-related issues. For more information on SQL SENTRY, visit our website today: http://www.sqlSentry.net/ ================================================================= ================================================================= Win & Learn: FREE SOFTWARE in the January Forum Contest! ================================================================= SQL-Server-Performance.Com, along with 9 companies (see below) have teamed up to give away FREE SQL Server software to each of 9 WINNERS (one prize per winner) of the January 2004 Forum Posting Contest. Participating in the forum is not only a great way to win free software, but to learn a lot more about how to get the most out of SQL Server. --ApexSQL Code Generator ($399) from ApexSQL Software http://www.apexsql.com --NetworkSmart 2003 ($449) from LeadByte Software http://www.leadbyte.com --SQL Scribe Documentation Builder ($400) from A&G Software http://www.ag-software.com --DbNetGrid ($599) from DBNetLink http://www.dbnetgrid.com --myLittleAdmin ($490) from myLittleTools.net http://www.mylittletools.net --SQLZip ($500) from SQLZip Software http://www.sqlzip.com --mssqlXpress ($199) from XpressApps http://www.xpressapps.com RapTier Professional ($299) from SharpPower.Com http://www.sharppower.com Find Duplicates Wizard for SQL Server ($397) from Azlexica http://www.findduplicates.com The first place winner will get the first pick of the above free software, the second place winner will get the second pick, the third place winner will get the third pick, and so on. We have also changed the rules for the forum contest, making it even easier for participants to win. To find out about this contest, and how you can participate, please visit this webpage: http://www.sql-server-performance.com/ ================================================================= ================================================================= There are only three ways you could have received this e-mail, and that is to have subscribed to it, joined our forum, or to have received it from a friend who forwarded it to you. This is a 100% opt-in newsletter. To learn how to advertise in this publication, visit: http://www.sql-server-performance.com/sponsor_information.asp To subscribe to this newsletter, visit: http://www.sql-server-performance.com/subscribe_newsletter.asp To unsubscribe to this newsletter, or to change your e-mail address, click on this URL. ================================================================= Copyright 2004 Brad M. McGehee. All rights reserved. No part of this newsletter may be reproduced in whole or in part without written permission. ================================================================= From owner-freebsd-chat@FreeBSD.ORG Wed Jan 21 17:14:00 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68BBA16A4CE for ; Wed, 21 Jan 2004 17:14:00 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B72FC43D53 for ; Wed, 21 Jan 2004 17:13:58 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 9F91A2BD75 for ; Thu, 22 Jan 2004 12:13:56 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 72B3151206; Thu, 22 Jan 2004 11:43:54 +1030 (CST) Date: Thu, 22 Jan 2004 11:43:54 +1030 From: Greg 'groggy' Lehey To: Rahul Siddharthan Message-ID: <20040122011354.GG86671@wantadilla.lemis.com> References: <20040107041307.GA1674@online.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5FDBdOf8+srCecG/" Content-Disposition: inline In-Reply-To: <20040107041307.GA1674@online.fr> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: Brad Knowles cc: chat@freebsd.org Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 01:14:00 -0000 --5FDBdOf8+srCecG/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry to drag this thread on, but I've just got round to looking at it, and I see a thing I need to clarify. On Tuesday, 6 January 2004 at 23:13:07 -0500, Rahul Siddharthan wrote: > Brad Knowles wrote: > [ ... Matt Dillon ... ] >>> OK, I've never run into that. Over on the DragonFly stuff, he seems >>> pleasant enough and his ideas are innovative, strong, if sometimes... >>> *cough*... eccentric (e.g. replacing sysinstall with an Apache server >>> and a load of PHP...), but I'll accept I haven't seen that, and I >>> know others have had their problems there. >> >> Well, since it's his project, I'm sure he feels a lot more >> secure. > > No, I have exactly the same impression from his FreeBSD mailing list > postings too, and many others said the same thing when he was chucked > out. He was always willing to help inexperienced people and his mails > were a pleasure to read for their technical detail. The impression > given out then (eg, by Greg Lehey in DaemonNews) was that he had two > faces to his personality: the friendly help-newbies one, and an > aggressive behind-the-scenes one that only showed up when dealing with > other developers. Hmm, that's not quite what I meant. Matt's usually friendly and helpful with other developers too. He just doesn't handle it gracefully when people push him around. That's hardly surprising, but I think that it upsets Matt even more than it upsets most people. Greg -- See complete headers for address and phone numbers. --5FDBdOf8+srCecG/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFADyPSIubykFB6QiMRAoTOAKCWTiJ0mXvQIvTaYIN60TX5U5BcVQCgjjiM f/jFwWBGs1zlAVsfH3+bBzI= =tsVu -----END PGP SIGNATURE----- --5FDBdOf8+srCecG/-- From owner-freebsd-chat@FreeBSD.ORG Wed Jan 21 22:38:45 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DEBC16A4CE for ; Wed, 21 Jan 2004 22:38:45 -0800 (PST) Received: from pcp04376046pcs.oakrdg01.tn.comcast.net (pcp04376046pcs.oakrdg01.tn.comcast.net [68.34.210.200]) by mx1.FreeBSD.org (Postfix) with SMTP id E6C2743D3F for ; Wed, 21 Jan 2004 22:37:48 -0800 (PST) (envelope-from yuzauzqu@terra.com) Received: from [68.34.210.200] by 3002hosting.comIP with HTTP; Thu, 22 Jan 2004 11:37:27 +0600 From: "Lanier" To: chat@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [3002hosting.comIP] Date: Thu, 22 Jan 2004 00:38:27 -0500 Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: IBO, the coat rack X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lanier List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 06:38:45 -0000 sex cadaver dayton sec snagging seaboard amide apologetic nobleman conferring beget sirius shenanigan congo cadenza scm allotted pontific whose baxter hoot binghamton tonal catholicism From owner-freebsd-chat@FreeBSD.ORG Thu Jan 22 16:44:06 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74ED816A4CF for ; Thu, 22 Jan 2004 16:44:06 -0800 (PST) Received: from eng.imakenews.com (mailservice6.imakenews.com [65.214.61.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC6AF43D46 for ; Thu, 22 Jan 2004 16:43:54 -0800 (PST) (envelope-from imaginis@jhill.imakenews.net) Received: by eng.imakenews.com (PowerMTA(TM) v2.0r6) id h21n3004om84; ) Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 22 Jan 2004 19:15:19 -0500 Errors-To: imaginis@jhill.imakenews.net From: "Imaginis.com" MIME-Version: 1.0 Message-Id: <20347.1074816919.jhill.a2wk90R.a1B2nlwF@imakenews.net> Precedence: normal Sender: "Imaginis.com" To: freebsd-chat@freebsd.org X-Imn: jhill,a2wk90R,a1B2nlwF,0 Subject: IMAGINIS.COM BREAST HEALTH NEWSLETTER VOLUME 6, ISSUE 1 X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: "Imaginis.com" List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2004 00:44:06 -0000 To view this newsletter in full-color: http://www.imakenews.com/jhill/index000045754.cfm?x=a2wk90R,a1B2nlwF IMAGINIS.COM BREAST HEALTH NEWSLETTER VOLUME 5, ISSUE 15 ----------------------------------------------------------------- Thursday, January 22, 2004 VOLUME 6, ISSUE 1 ----------------------------------------------------------------- IN THIS ISSUE ----------------------------------------------------------------- 1. IMAGINIS.COM WOMEN'S HEALTH NEWS AND INFORMATION 2. BISPHOSPONATE DRUGS HELPFUL IN BREAST CANCER PATIENTS WHOSE CANCER HAS SPREAD TO THE BONE 3. TAMOXIFEN EFFECTIVE IN OBESE AND LEAN WOMEN 4. BREAST CANCER DRUG, FEMARA, DRAMATICALLY IMPROVES SURVIVAL ODDS WHEN TAKEN AFTER TAMOXFEN 5. TREATING OSTEOPOROSIS ----------------------------------------------------------------- ----------------------------------------------------------------- IMAGINIS.COM WOMEN'S HEALTH NEWS AND INFORMATION http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C26568%2Ca2wk90R ----------------------------------------------------------------- FULL STORY: http://www.imakenews.com/jhill/e_article000220469.cfm?x=a2wk90R,a1B2nlwF ----------------------------------------------------------------- BISPHOSPONATE DRUGS HELPFUL IN BREAST CANCER PATIENTS WHOSE CANCER HAS SPREAD TO THE BONE http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C124273%2Ca2wk90R ----------------------------------------------------------------- FULL STORY: http://www.imakenews.com/jhill/e_article000220470.cfm?x=a2wk90R,a1B2nlwF ----------------------------------------------------------------- TAMOXIFEN EFFECTIVE IN OBESE AND LEAN WOMEN http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C124274%2Ca2wk90R ----------------------------------------------------------------- FULL STORY: http://www.imakenews.com/jhill/e_article000220471.cfm?x=a2wk90R,a1B2nlwF ----------------------------------------------------------------- BREAST CANCER DRUG, FEMARA, DRAMATICALLY IMPROVES SURVIVAL ODDS WHEN TAKEN AFTER TAMOXFEN http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C124275%2Ca2wk90R ----------------------------------------------------------------- FULL STORY: http://www.imakenews.com/jhill/e_article000220472.cfm?x=a2wk90R,a1B2nlwF ----------------------------------------------------------------- TREATING OSTEOPOROSIS http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C124276%2Ca2wk90R ----------------------------------------------------------------- FULL STORY: http://www.imakenews.com/jhill/e_article000220473.cfm?x=a2wk90R,a1B2nlwF _________________________________________________________________ Published by Imaginis.com (mailto:imaginis@mindspring.com) Copyright (C) 2004 Imaginis.com. All rights reserved. MEDICAL DISCLAIMER: INFORMATION IN THIS NEWSLETTER, WITHIN THE IMAGINIS.COM WEBSITE OR IN OTHER SITES LINKED TO FROM THE IMAGINIS.COM WEBSITE SHOULD NOT BE USED FOR SELF-TREATMENT. THE INFORMATION FOUND IN THIS NEWSLETTER, IN THE IMAGINIS.COM WEBSITE AND IN WEBSITES OR PUBLICATIONS LINKED TO FROM THE IMAGINIS.COM WEBSITE SHOULD BE USED FOR EDUCATIONAL PURPOSES ONLY AND IS NOT INTENDED TO BE USED AS A SUBSTITUTE FOR DIAGNOSIS AND TREATMENT BY A MEDICAL DOCTOR. USE OF THIS NEWSLETTER IS SUBJECT TO THE TERMS AND CONDITIONS OF USE FOUND ON IMAGINIS.COM AT http://www.imakenews.com/eletra/go.cfm?z=jhill%2C45754%2Ca1B2nlwF%2C26571%2Ca2wk90R . IMAGINIS.COM DOES NOT ENDORSE AND HAS NO RESPONSIBILITY FOR THE CONTENT OF ANY OTHER SITES LISTED ON IMAGINIS.COM, AND PROVIDES LINKS AND REFERENCES MERELY AS A CONVENIENCE TO ITS USERS. SEEK IMMEDIATE MEDICAL ATTENTION IF YOUR CONDITION IS URGENT. Copyright 2002, Imaginis Corporation. All rights reserved. -|________________ POWERED BY: http://www.imninc.com >From Imaginis.com, 1200 Lake Ridge Court, Roswell, Georgia 30076 USA To be removed from this list, use this link: http://www.imakenews.com/eletra/r.cfm?x=jhill%2Ca1B2nlwF%2Ca2wk90R To receive future messages in HTML format, use this link: http://www.imakenews.com/eletra/change.cfm?x=jhill%2Ca1B2nlwF%2Chtm From owner-freebsd-chat@FreeBSD.ORG Thu Jan 22 22:21:42 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9371D16A4CF for ; Thu, 22 Jan 2004 22:21:42 -0800 (PST) Received: from mailsrv.fph.co.uk (mailsrv.fph.co.uk [212.113.202.17]) by mx1.FreeBSD.org (Postfix) with SMTP id C199A43D5A for ; Thu, 22 Jan 2004 22:21:27 -0800 (PST) (envelope-from lostpassword@futurenet.co.uk) Received: (qmail 23067 invoked from network); 23 Jan 2004 06:22:56 -0000 Received: from unknown (HELO mailsrv2.fph.co.uk) (192.168.100.12) by 192.168.100.17 with SMTP; 23 Jan 2004 06:22:56 -0000 Received: from mail pickup service by mailsrv2.fph.co.uk with Microsoft SMTPSVC; Fri, 23 Jan 2004 06:18:31 +0000 From: To: Date: Fri, 23 Jan 2004 06:18:30 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 23 Jan 2004 06:18:31.0111 (UTC) FILETIME=[B8E90570:01C3E178] Subject: Future Newsletters : Your lost password X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: lostpassword@futurenet.co.uk List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2004 06:21:42 -0000 Thank you for using Future Newsletters where you can find the latest news, reviews, articles and special offers from your favourite magazine. We have received your request for information about a forgotten password. The email address you used was freebsd-chat@freebsd.org Your 8 character password is BHIEENDF If you did not request this notice, please ignore this message. Your Future Newsletters account and current password have not been affected. If you have further problems in accessing your Future Newsletters account, please contact lostpassword@futurenet.co.uk. Regards, Future Newsletters. www.futurenewsletters.com From owner-freebsd-chat@FreeBSD.ORG Sat Jan 24 17:41:54 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B35416A4CE for ; Sat, 24 Jan 2004 17:41:54 -0800 (PST) Received: from smithers.nildram.co.uk (smithers.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8337943D1F for ; Sat, 24 Jan 2004 17:41:53 -0800 (PST) (envelope-from mark@ukug.uk.freebsd.org) Received: from ukug.uk.freebsd.org (parish.gotadsl.co.uk [62.3.235.43]) by smithers.nildram.co.uk (Postfix) with ESMTP id 1B45824E1A1 for ; Sun, 25 Jan 2004 01:41:39 +0000 (GMT) Message-ID: <40131EE3.9070807@ukug.uk.freebsd.org> Date: Sun, 25 Jan 2004 01:41:55 +0000 From: Mark Ovens User-Agent: Mozilla Thunderbird 7.0 (Windows/20040120) X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: chat@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: OMG!!!!!! X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 01:41:54 -0000 Now we know for certain that Britain has gone stark staring mad...... http://tinyurl.com/2teet but then Betty is getting on a bit, obviously going senile. From owner-freebsd-chat@FreeBSD.ORG Sat Jan 24 17:56:33 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2903516A4CE for ; Sat, 24 Jan 2004 17:56:33 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 023ED43D1D for ; Sat, 24 Jan 2004 17:56:31 -0800 (PST) (envelope-from judmarc@fastmail.fm) X-Sasl-enc: w3CxESomon/uxm3pIkGewQ 1074995787 Received: from du191007.iro.ptd.net (du191007.iro.ptd.net [216.144.191.7]) by mail.messagingengine.com (Postfix) with ESMTP id E5C7F4B3FDF; Sat, 24 Jan 2004 20:56:23 -0500 (EST) Date: Sat, 24 Jan 2004 20:56:23 -0500 To: algould@datawok.com, jesse@wingnet.net, freebsd-chat@freebsd.org References: <200401232340.40104.bsd@elkins.org> <200401241617.05108.algould@datawok.com> From: Jud Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200401241617.05108.algould@datawok.com> User-Agent: Opera M2/7.50 (Win32, build 3544) Subject: Re: Why BSD? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 01:56:33 -0000 On Sat, 24 Jan 2004 16:17:04 -0600, Andrew L. Gould wrote: > On Saturday 24 January 2004 03:26 pm, Jesse Guardiani wrote: >> Occasion 2.) Got sick of Win 98 SE on my wife's computer, so I decided >> to >> "give Linux a second chance". >> >> This time I WANTED to go with Red Hat, since it's arguably >> the >> most popular Linux distro. However, one look at their new licensing >> made me >> change my mind in favor of Gentoo - The most BSD-like Linux distro. > > Slackware + portage would be interesting. The two Linux distros I've tried are Gentoo and Slackware, and I heartily agree with that sentiment. One thing that I thought was very nice about Slackware's text-based installer was the relatively verbose information on the installer screens. I'm sure smarter folks than I have considered whether to include something like this in FreeBSD's installer and decided against it for good reasons, but just thought I'd comment that the Slackware installer's hints were quite helpful to me as a Linux newbie. Jud