From owner-freebsd-chat Mon Jul 15 5:41:13 2002 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 16EBB37B400 for ; Mon, 15 Jul 2002 05:41:12 -0700 (PDT) Received: from supai.oit.umass.edu (supai.oit.umass.edu [128.119.175.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 359A543E42 for ; Mon, 15 Jul 2002 05:41:11 -0700 (PDT) (envelope-from gpav@som.umass.edu) Received: from CONVERSION-DAEMON by supai.oit.umass.edu (PMDF V5.2-32 #38130) id <0GZA00701J3BIY@supai.oit.umass.edu> for freebsd-chat@freebsd.org; Mon, 15 Jul 2002 08:38:00 -0400 (EDT) Received: from yolen.oit.umass.edu (yolen.oit.umass.edu [128.119.166.35]) by supai.oit.umass.edu (PMDF V5.2-32 #38130) with ESMTP id <0GZA0071HJ3BGW@supai.oit.umass.edu> for freebsd-chat@freebsd.org; Mon, 15 Jul 2002 08:37:59 -0400 (EDT) Received: from localhost (gp@localhost) by yolen.oit.umass.edu (8.12.1/8.12.1/Submit) with ESMTP id g6FCbx8Q007220 for ; Mon, 15 Jul 2002 08:37:59 -0400 (EDT) Date: Mon, 15 Jul 2002 08:37:59 -0400 (EDT) From: Gregory Pavelcak Subject: Naive networking question X-Sender: gp@yolen.oit.umass.edu To: freebsd-chat@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: yolen.oit.umass.edu: gp owned process doing -bs Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm thinking about getting AT&T broadband. According to their website, if you want to have access on several PCs simultaneously, you need a switch and additional IP addresses. I assume they're not giving static addresses. Can I just use a hub, let the PCs setup DHCP and have access from all them simultaneously? PC / World-------Cable Modem----Hub----PC \ PC Thanks. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Jul 15 5:53:34 2002 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 078B937B400 for ; Mon, 15 Jul 2002 05:53:32 -0700 (PDT) Received: from proxy.centtech.com (moat.centtech.com [206.196.95.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42F4043E64 for ; Mon, 15 Jul 2002 05:53:31 -0700 (PDT) (envelope-from anderson@centtech.com) Received: from sprint.centtech.com (sprint.centtech.com [10.177.173.31]) by proxy.centtech.com (8.11.6/8.11.6) with ESMTP id g6FCrT123046; Mon, 15 Jul 2002 07:53:29 -0500 (CDT) Received: (from root@localhost) by sprint.centtech.com (8.11.6+Sun/8.11.6) id g6FCrTm24294; Mon, 15 Jul 2002 07:53:29 -0500 (CDT) Received: from centtech.com (proton [10.177.173.77]) by sprint.centtech.com (8.11.6+Sun/8.11.6) with ESMTP id g6FCrQ924287; Mon, 15 Jul 2002 07:53:26 -0500 (CDT) Message-ID: <3D32C5C6.30809@centtech.com> Date: Mon, 15 Jul 2002 07:53:26 -0500 From: Eric Anderson Reply-To: anderson@centtech.com User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Pavelcak Cc: freebsd-chat@freebsd.org Subject: Re: Naive networking question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You'll need a NAT box in between, like: PC / World-------Cable Modem--NAT/firewall--Hub----PC \ PC Of course, you can use FreeBSD for the NAT/firewall box.. :) Eric Gregory Pavelcak wrote: > I'm thinking about getting AT&T broadband. According to their website, > if you want to have access on several PCs simultaneously, you need > a switch and additional IP addresses. I assume they're not giving > static addresses. Can I just use a hub, let the PCs setup DHCP and have > access from all them simultaneously? > > > PC > / > World-------Cable Modem----Hub----PC > \ > PC > > Thanks. > > Greg > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message -- ------------------------------------------------------------------ Eric Anderson Systems Administrator Centaur Technology For Sale: Parachute. Only used once, never opened, small stain. ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Jul 15 9:17:43 2002 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 C3D8C37B400 for ; Mon, 15 Jul 2002 09:17:39 -0700 (PDT) Received: from mail19b.rapidsite.net (mail19b.rapidsite.net [161.58.134.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E28E43E64 for ; Mon, 15 Jul 2002 09:17:39 -0700 (PDT) (envelope-from rob@pythonemproject.com) Received: from www.pythonemproject.com (198.104.176.109) by mail19b.rapidsite.net (RS ver 1.0.63s) with SMTP id 076092019 for ; Mon, 15 Jul 2002 12:25:14 -0400 (EDT) Message-ID: <3D32F50F.267322E2@pythonemproject.com> Date: Mon, 15 Jul 2002 09:15:11 -0700 From: rob X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-chat@freebsd.org Subject: Re: Naive networking question References: <3D32C5C6.30809@centtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-chat@freebsd.org X-Loop-Detect: 1 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have attbi and I just pay the extra $2 or $3 per ip address. I don't use NAT as I want the redundancy of my machines. They use DHCP only, but I've found that my IP address never changes, so I can set up SSH, SSHD, and Freenet. You need to manually add the entry in /etc/hosts as DHCPD doesn't do this on its own, if you want to use X11 forwarding or get rid of annoying messages everytime you start X. I have noticed that on accasion they change the default router and mask, which means my SSH X11 forwarding slows down from 100MB/s (since it was on the same subnet) to 256k/s. One drawback is that they have no reverse dns to your dhcp address, so if you use sendmail or qmail, your mail might get bounced, but then thats all illegal in the TOS anyway. I expect them at any time to set up a tiered service. Rob. Eric Anderson wrote: > > You'll need a NAT box in between, like: > PC > / > World-------Cable Modem--NAT/firewall--Hub----PC > \ > PC > > Of course, you can use FreeBSD for the NAT/firewall box.. :) > > Eric > > Gregory Pavelcak wrote: > > I'm thinking about getting AT&T broadband. According to their website, > > if you want to have access on several PCs simultaneously, you need > > a switch and additional IP addresses. I assume they're not giving > > static addresses. Can I just use a hub, let the PCs setup DHCP and have > > access from all them simultaneously? > > > > > > PC > > / > > World-------Cable Modem----Hub----PC > > \ > > PC > > > > Thanks. > > > > Greg > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-chat" in the body of the message > > -- > ------------------------------------------------------------------ > Eric Anderson Systems Administrator Centaur Technology > For Sale: Parachute. Only used once, never opened, small stain. > ------------------------------------------------------------------ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Jul 15 12:41: 0 2002 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 730F937B4F7 for ; Mon, 15 Jul 2002 12:40:44 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1871043E6D for ; Mon, 15 Jul 2002 12:40:43 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (patr530-b146.otenet.gr [212.205.244.154]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g6FJe7sC006774; Mon, 15 Jul 2002 22:40:09 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g6FJe7ft058942; Mon, 15 Jul 2002 22:40:07 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g6FJe6pW058941; Mon, 15 Jul 2002 22:40:06 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 15 Jul 2002 22:40:06 +0300 From: Giorgos Keramidas To: David Varieur Cc: morinfen@acmemail.net, freebsd-chat@freebsd.org Subject: Re: i love you product so much... Message-ID: <20020715194006.GA58838@hades.hell.gr> References: <1026760527.3d331f4f446b9@www.acmemail.net> <20020715123004.35dffd36.davar@mwvcaa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020715123004.35dffd36.davar@mwvcaa.org> X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-07-15 12:30 +0000, David Varieur wrote: > On Mon, 15 Jul 2002 12:15:27 -0700 morinfen@acmemail.net wrote: > > i have been an avid freeBSD fan for 3 years now, [...] > > Cool, but on the off chance FreeBSD ever fails to provide you with a > reason for being, let me tell you about a few things that I'm a big > fan of: > > Sunlight > Girls > Beer Never, but I mean *never*, absolutely *NEVER* mix the third part with any of the former two. Statistically speaking you'll end up either drunk and burned in lots of funny places or worse :P - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Jul 15 19:52:15 2002 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 1132137B400 for ; Mon, 15 Jul 2002 19:52:13 -0700 (PDT) Received: from 1nova.com (heorot.1nova.com [63.105.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABD3F43E58 for ; Mon, 15 Jul 2002 19:52:12 -0700 (PDT) (envelope-from hamellr@heorot.1nova.com) Received: by 1nova.com (Postfix, from userid 1000) id C3E9D18F9; Mon, 15 Jul 2002 20:53:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by 1nova.com (Postfix) with ESMTP id BB25418F8; Mon, 15 Jul 2002 20:53:10 -0700 (PDT) Date: Mon, 15 Jul 2002 20:53:10 -0700 (PDT) From: Rick Hamell To: Giorgos Keramidas Cc: freebsd-chat@freebsd.org Subject: Re: i love you product so much... In-Reply-To: <20020715194006.GA58838@hades.hell.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Cool, but on the off chance FreeBSD ever fails to provide you with a > > reason for being, let me tell you about a few things that I'm a big > > fan of: > > > > Sunlight > > Girls > > Beer > > Never, but I mean *never*, absolutely *NEVER* mix the third part with > any of the former two. Statistically speaking you'll end up either > drunk and burned in lots of funny places or worse :P Married? Rick ******************************************************************* New home page: http://1nova.com Ace Logan's Hardware Guide @ http://www.markeedragon.com FreeBSD - The power to Serve! http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 4:49:54 2002 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 1C37237B401 for ; Tue, 16 Jul 2002 04:49:52 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-156-170.client.attbi.com [12.233.156.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBDC643E64 for ; Tue, 16 Jul 2002 04:49:11 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.wox.org (localhost [127.0.0.1]) by HAL9000.wox.org (8.12.3/8.12.3) with ESMTP id g6G6bX3d000333; Mon, 15 Jul 2002 23:37:34 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.wox.org (8.12.3/8.12.3/Submit) id g6G6bM4x000332; Mon, 15 Jul 2002 23:37:22 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 15 Jul 2002 23:37:21 -0700 From: David Schultz To: rob Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Naive networking question Message-ID: <20020716063721.GA239@HAL9000.wox.org> Mail-Followup-To: rob , freebsd-chat@FreeBSD.ORG References: <3D32C5C6.30809@centtech.com> <3D32F50F.267322E2@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D32F50F.267322E2@pythonemproject.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake rob : > They use DHCP only, but I've found that my IP address never changes, so > I can set up SSH, SSHD, and Freenet. You need to manually add the entry > in /etc/hosts as DHCPD doesn't do this on its own, if you want to use > X11 forwarding or get rid of annoying messages everytime you start X. I > have noticed that on accasion they change the default router and mask, > which means my SSH X11 forwarding slows down from 100MB/s (since it was > on the same subnet) to 256k/s. One drawback is that they have no > reverse dns to your dhcp address, so if you use sendmail or qmail, your > mail might get bounced, but then thats all illegal in the TOS anyway. They only change your IP address if you don't renew your DHCP lease often enough. Unless there was a recent change in their network, your router address is always ${ip%.*}.1, so I'm not sure why yours would change while your IP addresses remain constant. The formula to generate the gateway address even used to be in some of their documentation. Reverse lookup should work, by the way. It was broken for a short time after @Home pulled the plug on AT&T subscribers, but mail generally works fine now. The exception is people who blackhole AT&T's netblocks. I have only noticed two people who do this, one of whom is Eric Anderson. ;-) If you care enough, you can always work around that provided that you have a login on a machine with a more respectable Internet connection. However, I don't recommend using AT&T's mail services; I have recently noticed that their servers don't always get the mail delivered. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 5: 3:49 2002 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 D5BF237B400 for ; Tue, 16 Jul 2002 05:03:47 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE87043E64 for ; Tue, 16 Jul 2002 05:03:45 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (patr530-b127.otenet.gr [212.205.244.135]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g6GC3g1x000865; Tue, 16 Jul 2002 15:03:43 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g6GC3fUd004966; Tue, 16 Jul 2002 15:03:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g6GC3eQ3004965; Tue, 16 Jul 2002 15:03:40 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 16 Jul 2002 15:03:39 +0300 From: Giorgos Keramidas To: Rick Hamell Cc: freebsd-chat@freebsd.org Subject: Re: i love you product so much... Message-ID: <20020716120339.GD1302@hades.hell.gr> References: <20020715194006.GA58838@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-07-15 20:53 +0000, Rick Hamell wrote: > > > Cool, but on the off chance FreeBSD ever fails to provide you with a > > > reason for being, let me tell you about a few things that I'm a big > > > fan of: > > > > > > Sunlight > > > Girls > > > Beer > > > > Never, but I mean *never*, absolutely *NEVER* mix the third part with > > any of the former two. Statistically speaking you'll end up either > > drunk and burned in lots of funny places or worse :P > > Married? That's one of `not so bad' options. I can think of a few unpleasant things that can happen to drunk lads who make passes at girls unwilling to give in to their .. efforts :-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 17:25:21 2002 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 C85F037B400 for ; Tue, 16 Jul 2002 17:25:16 -0700 (PDT) Received: from relay2.kornet.net (relay2.kornet.net [211.48.62.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3538743E31 for ; Tue, 16 Jul 2002 17:25:16 -0700 (PDT) (envelope-from ggaggung14@kornet.net) Received: from you14-7tvw5pot5 (61.73.137.216) by relay2.kornet.net; 17 Jul 2002 09:25:12 +0900 Message-ID: <3d34b96a3d627837@relay2.kornet.net> (added by relay2.kornet.net) From: =?ks_c_5601-1987?B?v+y4rsSrteUgyLi/+L+1vvcgxsDA5Q==?= To: chat@freebsd.org Subject: =?ks_c_5601-1987?B?W7GksO1dIGNoYXS01CDA57nMwNa0wiC758C6x7DAuyC15biztM+02S4=?= Date: Wed, 17 Jul 2002 08:29:52 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C0F29A.93A52C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C0F29A.93A52C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 v+y4rsSrteUgICAgDQoNCiAgICAgDQogICAgCQkJCQkJILy6uO0gIAkJICDB1rnOte63zyC5 +MijICANCsH3wOUgwPzIrSAgICAgIMjetOvG+SAgCSAgICAgDQogICANCiAgICAgILHNx8/A xyAguN7Az8HWvNK0wiDApbytx87AuyDF68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7raw x9EgwaS6uLW1ILCusO0gIMDWwfYgvsrAvcC7ILngyPy0z7TZLg0KICDAzCBFLW1haWzAuiC5 373FwPy/68DMuOcsIL/4xKEgvsrAuL3HICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rimIMDU t8LHz7+pIMHWvcO46SC1ziC5+CC02b3DILjewM8gIMDMICCwocH2IL7KtbW3zyDHz7DavcC0 z7TZLg0KICAgICAJICC89r3FsMW6ziAgLyByZWZ1c2FsIG9mIHJlY2VpcHQgICAJICAgIAkg IA0KIA0KDQogDQo= ------=_NextPart_000_0087_01C0F29A.93A52C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPFNDUklQVCBsYW5ndWFnZT1qYXZhc2NyaXB0Pg0KPCEtLQ0K ZnVuY3Rpb24gY2xpY2tNb3VzZSgpDQoJew0KCSAgDQoJCWlmICgoZXZlbnQuYnV0dG9uPT0y KSB8fCAoZXZlbnQuYnV0dG9uPT0zKSl7DQoJCQlyZXR1cm4gKGZhbHNlKTsNCgkJfQkNCgl9 DQoJDQoJZnVuY3Rpb24gY2xpY2tLZXkoKQ0KCXsNCgkJaWYoKGV2ZW50LnNoaWZ0S2V5KSAm JiAoZXZlbnQua2V5Q29kZSA9PSAxMjEpKQ0KCQl7CQkNCgkJCXJldHVybiBmYWxzZTsNCgkJ fQkNCgl9DQoJDQoJZnVuY3Rpb24gbm9BY3Rpb24oKXsNCgkJcmV0dXJuIGZhbHNlOw0KCX0N Cg0KZG9jdW1lbnQub25tb3VzZWRvd249Y2xpY2tNb3VzZQ0KZG9jdW1lbnQub25rZXlkb3du PWNsaWNrS2V5DQpkb2N1bWVudC5vbmNvbnRleHRtZW51PW5vQWN0aW9uDQpkb2N1bWVudC5v bmRyYWdzdGFydD1ub0FjdGlvbg0KZG9jdW1lbnQub25zZWxlY3RzdGFydD1ub0FjdGlvbg0K Ly8tLT4NCjwvU0NSSVBUPg0KDQoNCg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT6/7LiuxKu1 5SAgPC90aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgdGV4dD0i YmxhY2siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiPg0KPHRhYmxl IGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1ODki IGhlaWdodD0iOTIiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9 ImJsYWNrIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNTkyIiBjb2xzcGFuPSIy Ij4NCiAgICAgICAgICAgIDxwPjxpbWcgc3JjPSJodHRwOi8vd3d3Lml5ZXNjYXJkLmNvbS9p bWFnZS90b3BfNy5naWYiIHdpZHRoPSI1OTciIGhlaWdodD0iOTIiIGJvcmRlcj0iMCI+PC9w Pg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lk dGg9IjU5MiIgY29sc3Bhbj0iMiI+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvYm90dG9tNi5naWYiIHdp ZHRoPSI1OTciIGhlaWdodD0iMjExIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4N CiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODkiIGNvbHNwYW49 IjIiPg0KCQkJCQk8Zm9ybSBuYW1lPSJtYWlsZnJtIiBhY3Rpb249Imh0dHA6Ly93d3cuaXdv b3JpY2FyZC5jb20vbWFpbC9pbnNlcnQxLmFzcCIgbWV0aG9kPSJwb3N0IiA+CQ0KICAgICAg ICAgICAgPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtaW5kZW50Oi0xOyBsaW5lLWhl aWdodDowOyBtYXJnaW46MDsiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij68urjt PC9mb250Pjxmb250IHNpemU9IjIiPiAgDQogICAgICAgICAgPC9mb250PjxpbnB1dCB0eXBl PSJ0ZXh0IiBuYW1lPSJuYW1lIiBzaXplPSI2Ij4NCgkJICAmbmJzcDs8Zm9udCBzaXplPSIy IiBjb2xvcj0iIzY2NjY2NiI+wda5zrXut88gufjIoyA8L2ZvbnQ+PGlucHV0IHR5cGU9InRl eHQiIG5hbWU9Imp1bWluIiBzaXplPSIxNCIgbWF4bGVuZ3RoPSIxNCI+DQogICAgICAgICAg PGJyPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij7B98DlIMD8yK0gIA0KICAgICAg ICAgIDwvZm9udD48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0idGVsbnVtIiBzaXplPSIxMyI+ DQogICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2 NjY2NjYiPsjetOvG+SA8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PGlucHV0IHR5cGU9InRleHQi IG5hbWU9ImhhbmRudW0iIHNpemU9IjE1Ij4NCiAgICAgICAgICA8L2ZvbnQ+PGlucHV0IHR5 cGU9InN1Ym1pdCIgbmFtZT0iU3VibWl0MiIgdmFsdWU9Ir3Fw7siPiA8L2Zvcm0+DQoNCgkN CiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRo PSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6 Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50MS5naWYiIHdpZHRoPSIyOTQiIGhlaWdo dD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdp ZHRoPSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0 dHA6Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50Mi5naWYiIHdpZHRoPSIyOTQiIGhl aWdodD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1OTIiIGNvbHNwYW49IjIiPg0KICAgICAg ICAgICAgPHAgYWxpZ249ImxlZnQiPiZuYnNwOzxmb250IHNpemU9IjIiIGZhY2U9IrG8uLIi IGNvbG9yPSIjNjY2NjY2Ij6xzcfPwMcgDQogICAgICAgICAgICC43sDPwda80rTCIMClvK3H zsC7IMXrx9ggvPbB/cfRILDNwMy45ywgsde/3L+hIL7utrDH0SDBpLq4tbUgsK6w7SANCiAg ICAgICAgICAgIMDWwfYgvsrAvcC7ILngyPy0z7TZLjxicj4gJm5ic3A7wMwgRS1tYWlswLog ud+9xcD8v+vAzLjnLCC/+MShIL7KwLi9xyANCiAgICAgICAgICAgILDmv+wgvsa3oSDDor+h ILjewM/B1rzSuKYgwNS3wsfPv6kgwda9w7jpILXOILn4ILTZvcMguN7AzyAmbmJzcDvAzCAN CiAgICAgICAgICAgILChwfYgvsq1tbfPIMfPsNq9wLTPtNkuPC9mb250PjwvcD4NCiAgICAg ICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODki IGNvbHNwYW49IjIiPg0KICA8Zm9ybSBuYW1lPSJtYWlsZnJtMiIgYWN0aW9uPSJodHRwOi8v d3d3Lml3b29yaWNhcmQuY29tL21haWwvbm8uYXNwIiBtZXRob2Q9InBvc3QiID4gIAkgIA0K ICAgICAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tbGVmdDow OyI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2NjY2NjYiPrz2vcWwxbrOIA0KICAgICAgICAg ICAgICAgIC8gcmVmdXNhbCBvZiByZWNlaXB0PC9mb250PiANCiAgICAgICAgICA8aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjI1Ij4NCiAgICAgICAgICA8aW5wdXQg dHlwZT0ic3VibWl0IiBuYW1lPSJTdWJtaXQiIHZhbHVlPSJFTlRFUiI+PC9mb3JtPgkNCiAg ICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1 ODkiIGNvbHNwYW49IjIiPg0KCTxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTsgbWFyZ2luLXJpZ2h0OjA7IG1hcmdpbi1sZWZ0OjA7Ij48aW1nIHNyYz0iaHR0cDov L3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvZjMuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYw IiBib3JkZXI9IjAiIGFsaWduPSJtaWRkbGUiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj4gICAg ICAgIDwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQo8cD4mbmJzcDs8L3A+DQo8cD4mbmJz cDs8L3A+DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg0K ------=_NextPart_000_0087_01C0F29A.93A52C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 17:52:28 2002 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 4455737B43D for ; Tue, 16 Jul 2002 17:52:15 -0700 (PDT) Received: from cs6668125-184.austin.rr.com (cs6668125-184.austin.rr.com [66.68.125.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3751143E42 for ; Tue, 16 Jul 2002 17:52:15 -0700 (PDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1]) by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id g6H0uUIU042777; Tue, 16 Jul 2002 19:56:30 -0500 (CDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: (from fracture@localhost) by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id g6H0uUTn042776; Tue, 16 Jul 2002 19:56:30 -0500 (CDT) Date: Tue, 16 Jul 2002 19:56:29 -0500 From: Jordan DeLong To: Terry Lambert Cc: Taavi Talvik , freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability Message-ID: <20020717005629.GA42607@allusion.net> References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <3D34AC52.2D882455@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Somewhat tangential, so going to -chat. On Tue, Jul 16, 2002 at 04:29:22PM -0700, Terry Lambert wrote: > Taavi Talvik wrote: > > Probably this belongs to questions, but anyway: > >=20 > > How portable is idea of using linker sets? Is it possible > > to use them (maybe using some preprocessor wizardry) on > > linux/solaris/win/etc? Do they have somewhat similiar facilities? >=20 > "Moderately portable". >=20 [ ... ] > Microsoft DLL's have that ability, derived from OLE, and based on > the current COM (Common Object Model) to create arbitrary support Component object model actually, I believe. > for aggregate objects. Specifically, Microsoft DLL's which are > instances of COM objects generally have "process attach" and > "process detach" entry points (equivalent to ".init" and ".fini" > in UNIX for the creation of global constructors and destructors). >=20 > They also have the ability to support arbitrary "thread attach" > and "thread detach" entry points. These are necessary to be able > to support "rental" and "apartment" model threading, which permits > you to create a thread-unsafe library, and maintain the ability to > use it from a threaded program anyway (UNIX is very behind Microsoft > here; an example is the LDAP and IMAP4 client libraries, both of > which could benefit from these models, but of course, the LDAP > libraries are generally not thread safe even on Win32, because > people don't know how to program to Windows threads models). If you spend a few moments playing with COM, you'd probably realize that the COM threading models are so painfully braindead it's not even funny (and they're a symptom of the rampant misuse of threading found in win32, not a sign of win32 being ahead of unix).=20 Basically if you want to use more than one appartment in the same process, you're going to have trouble (and keep in mind this is the whole theoretical point of the threading models): Because calls into the STA from other appartments are implemented by using a hidden "COM Window" and packaging every call into a windows message, anytime you enter a modal message pump from the main STA another thread can renter the STA's objects -- and there is *no* way to effectively lock them out as one would normally do in an MTA app because it's the same physical thread, even though it is a different "logical" thread (i.e. it would own any critical section objects already, etc). This behavior is entirely unpredictable and unavoidable, because you have no control over the internals IMessageFilter can't solve the problem, but i'm getting off track) of modal message pumps (which exist in several apis). OTOH if you put stuff into the MTA and try to access other pieces in an STA which may call back into it (the mta), win32 will actually spawn a new thread for every method call back into the MTA. So that's gross, but it's worse than just gross: because this is a differen't physical thread (but the same "logical" thread, if you take my meaning) it can't recurse on mutexes. I don't see why the win32 people couldn't have just done their component thing without regard to threading, and let individual app/component writers deal with it. It's just trying to solve too many (nonexistant) problems with one architecture (for more of this see their new COR/CLR/.NET (whatever it's called this week) replacement for COM+). [ ... ] > So the general answer is "pretty much everyone whose linker is > capable of linking programs compliant with the C++ standards, > and whose C compiler supports a sufficiently sophisticated ability > to escape to inline assebly to generate the data that the linker > uses to accomplish C++ specific features, can be made to support > linker sets". OT: (This isn't important to the point you were making... but then again neither was the COM stuff above :P). I don't think a truely standards compliant C++ compiler exists... neither G++ nor MSVC++ comply to the standard completly.. --=20 Jordan DeLong fracture@allusion.net --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9NMC7DrrilS51AZ8RAhOfAKCZ8ESmO/U5D4EcZDJFFqg9SFNrRACdGENj ZC3PP99gM7aYrxQYOEXwu4E= =gH93 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 20: 0:59 2002 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 73B0837B400 for ; Tue, 16 Jul 2002 20:00:51 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBA5243E3B for ; Tue, 16 Jul 2002 20:00:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0573.cvx40-bradley.dialup.earthlink.net ([216.244.44.63] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17Uf3M-0006fo-00; Tue, 16 Jul 2002 20:00:36 -0700 Message-ID: <3D34DD99.11FF8526@mindspring.com> Date: Tue, 16 Jul 2002 19:59:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jordan DeLong Cc: Taavi Talvik , freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> <20020717005629.GA42607@allusion.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jordan DeLong wrote: > > Microsoft DLL's have that ability, derived from OLE, and based on > > the current COM (Common Object Model) to create arbitrary support > > Component object model actually, I believe. I don't know; "Common Object Model" is what they called it in the "ViPER Microsoft ActiveX Preview" back in June of 1996, when they gave me the CDROM to run on Microsoft Windows NT 4.0 Beta 2. 8-) 8-). > If you spend a few moments playing with COM, you'd probably realize > that the COM threading models are so painfully braindead it's not even > funny (and they're a symptom of the rampant misuse of threading found > in win32, not a sign of win32 being ahead of unix). I guess I'll have to turn in my "Microsoft ActiveX Server Design Team" T-Shirt at the front office? 8-). Actually, they are very natural, once you understand why they are the way they are. Specifically, the reasons behind the reasons behind marshalling have to do with WIN32.DLL on Windows 3.11. > Basically if you want to use more than one appartment in the same > process, you're going to have trouble (and keep in mind this is > the whole theoretical point of the threading models): > > Because calls into the STA from other appartments are implemented > by using a hidden "COM Window" and packaging every call into a > windows message, anytime you enter a modal message pump from the > main STA another thread can renter the STA's objects -- and there > is *no* way to effectively lock them out as one would normally do > in an MTA app because it's the same physical thread, even though > it is a different "logical" thread (i.e. it would own any critical > section objects already, etc). This behavior is entirely unpredictable > and unavoidable, because you have no control over the internals > IMessageFilter can't solve the problem, but i'm getting off track) > of modal message pumps (which exist in several apis). Actually, we faced this problem at Artisoft, when we implemented soft updates in 1995, after we ported the Heidemann VFS stacking framework and the Berkeley FFS to Windows95 (well before soft updates were supported on any BSD -- Matt Day did most of the work on the Soft Updates implementation). The trick is that you can't use a semaphore, you have to use a mutual exclusion. This bit us when the timer thread would fire for the kernel thread we had running the soft updates update clock, since it would basically grab any thread context to run on (like FreeBSD has been proposing to do for interrupt threads). If you use the real mutual exclusion primitives, rather than the semaphore calls, it's not a problem. For this to work, you have to "OpenDriver" a VXD that implements the exlusion mechanism using the kernel primitives. It's really pretty trivial, if you have the DDK license, which any (at the time) "MSDN Level 2" or better developer network member had (it was a matter of paying for the SDK's and DDK's, in other words). > OTOH if you put stuff into the MTA and try to access other pieces > in an STA which may call back into it (the mta), win32 will actually > spawn a new thread for every method call back into the MTA. So > that's gross, but it's worse than just gross: because this is a > differen't physical thread (but the same "logical" thread, if you > take my meaning) it can't recurse on mutexes. You never want recursion on mutexes. If your code recurses on mutexes, it's broken, unless you have explicit recursion counting so that you know it's happening. With "context stealing", there is really no way to make provably correct code, if you permit mutex recursion. So, actually, I would blame your code, not the ViPER framework. > I don't see why the win32 people couldn't have just done their > component thing without regard to threading, and let individual > app/component writers deal with it. It's just trying to solve too > many (nonexistant) problems with one architecture (for more of this > see their new COR/CLR/.NET (whatever it's called this week) replacement > for COM+). The problems it's solving are real. The Windows 3.11 system with the WIN32.DLL and the corresponding VxD in it was incapable if supporting a "freethreading" model. This is because the data in any heap memory was allocated in a 64K medium model chunk, the address of which was the instance ID for the message pump, when you were running multiple instances of messages. The best that they could do is to create the concept of TLS "Thread Local Storage", and live with it. For the programs to run on both Windows 3.11 with the WIN32 API spackled onto it, and on newer Windows95 and above versions, the concept of "marshalling" data to get it between one set of TLS and another was required. Actually, due to the way VMM32.VxD was written, you actually don't need to marshal object instances created *before* a thread is created -- there will be a duplicate mapping. In the free-threading case, there was an attempt to make the API compatible between NT and Windows 95/98. For that to work, the marshalling ("CoCreateFreeThreadedMarshaller()") was required, since the data may be in a different address space, and that's what enabled DCOM ("COM+" as you've called it). What Apartment model threading buys you is the ability to serialize requests into an otherwise unsafe legacy inteface, using a simple to write wrapper around the Thunk entry points. Rental model threading permits the use of local globals, so long as they aren't used simultaneously (in the FreeBSD world, this would be like implementing the interface "x_r()" via a set of locking primitives and a call to "x()"). Again, it permits a certain level of backward compatability, and, if the code is written correcly, it can attempt to set freethreding, fail to do so, and continue to run (in a degraded peroformance mode) successfully. Other than the different address spaces, which require marshalling on the local machine, and the registration and service location mechanisms, which are solvable with protocols like SLPv2, rather than jamming raw IP addresses into DCOM object server lists, Microsoft did a pretty incredible job with what they had. For implicitly serialized protocols, where pipelining is not a possibility, UNIX could really use the ability to rental or apartment model the libraries that interfaced to the protocol engine. Specifically, there has been a lot of recent bitching about the resolver library not being asynchornous. With an apartment model -- which requires the ability to know when threads attach and detach a library, so that the library can create/delete per thread context objects -- it's possible to export an asynchornous interface, while handling the serial nature of the current resolver library. Then code would not have to change, were the resolver library ever pulled out of libc, so that it could be easily fixed ("the BSD way" can be preserved by linking the ELF C library against the ELF resolv library: one of the base arguments used for the ELF switch in the first place). Similarly, all of the "x" and "x_r" versions of routines could have been resolved via "rental model", without having to introduce a new API. For each instance of a thread, there would be a late-bound allocation of a thread specific "global" context, and the APIs would "just work" without all the glue and kludgery that we see today. The contexts would be freed on "thread detach", so there would be no memory leak. Say what you will about them, they thought a number of these issues out, while UNIX has been sitting on it's academic laurels and doing nothing. > [ ... ] > > So the general answer is "pretty much everyone whose linker is > > capable of linking programs compliant with the C++ standards, > > and whose C compiler supports a sufficiently sophisticated ability > > to escape to inline assebly to generate the data that the linker > > uses to accomplish C++ specific features, can be made to support > > linker sets". > > OT: (This isn't important to the point you were making... but then > again neither was the COM stuff above :P). I don't think a truely > standards compliant C++ compiler exists... neither G++ nor MSVC++ > comply to the standard completly.. The point is that people have been trying to for a long time. It used to be that there were no shared template instances. Then, you had to compile a "magic" version of the template code with a compiler flag, to get a shared instance. Then the compilers started supporting auto-aggregation with duplicate supression, and all that garbage wasn't necessary any more. You can assume that linker sets are portable to the platforms he listed (Linux/FreeBSD/Win32/Solaris), and the "/..." is the part that needed his iown observations for answering. Most compilers these days *at least* support that much of the standard that you can have a template class with a static instance member variable that is shared among all instances; and if the compiler supports it, there's usually some way to abuse it to get a "linker set" equivalent, although whether it can be achieved inline is always a function of the flexibility of the C compiler itself (e.g. inline assembly and segment attribution, to access the linker feature that was intended for use by C++ for that purpose). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 21:23:13 2002 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 AD27237B400 for ; Tue, 16 Jul 2002 21:23:04 -0700 (PDT) Received: from cs6668125-184.austin.rr.com (cs6668125-184.austin.rr.com [66.68.125.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9B7443E3B for ; Tue, 16 Jul 2002 21:23:03 -0700 (PDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1]) by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id g6H4RPIU045511; Tue, 16 Jul 2002 23:27:25 -0500 (CDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: (from fracture@localhost) by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id g6H4ROAS045510; Tue, 16 Jul 2002 23:27:24 -0500 (CDT) Date: Tue, 16 Jul 2002 23:27:24 -0500 From: Jordan DeLong To: Terry Lambert Cc: Taavi Talvik , freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability Message-ID: <20020717042724.GA45349@allusion.net> References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> <20020717005629.GA42607@allusion.net> <3D34DD99.11FF8526@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D34DD99.11FF8526@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 16, 2002 at 07:59:37PM -0700, Terry Lambert wrote: > Jordan DeLong wrote: > > > Microsoft DLL's have that ability, derived from OLE, and based on > > > the current COM (Common Object Model) to create arbitrary support > > > > Component object model actually, I believe. > > I don't know; "Common Object Model" is what they called it in > the "ViPER Microsoft ActiveX Preview" back in June of 1996, > when they gave me the CDROM to run on Microsoft Windows NT 4.0 > Beta 2. 8-) 8-). http://www.microsoft.com/com/ calls it "Component". Possible they just renamed it (they have a history of renaming things and then pretending they are new). > > If you spend a few moments playing with COM, you'd probably realize > > that the COM threading models are so painfully braindead it's not even > > funny (and they're a symptom of the rampant misuse of threading found > > in win32, not a sign of win32 being ahead of unix). > > I guess I'll have to turn in my "Microsoft ActiveX Server Design > Team" T-Shirt at the front office? 8-). Ahh I was being rhetorical; not actually intending to suggest you hadn't played with it. > Actually, they are very natural, once you understand why they > are the way they are. Specifically, the reasons behind the > reasons behind marshalling have to do with WIN32.DLL on Windows > 3.11. I'm not interested in the history of any API. Historical crap (i.e. very ungraceful aging) is the reason the win32 api is so crufty. When interoperating with old code, there's no reason that people couldn't make their own wrappers which just syncronize entry across threads. Bundling it into the do-everything-object-model is just uncontrolled bloat, not to mention that STA doesn't really solve the problem. > > Basically if you want to use more than one appartment in the same > > process, you're going to have trouble (and keep in mind this is > > the whole theoretical point of the threading models): > > > > Because calls into the STA from other appartments are implemented > > by using a hidden "COM Window" and packaging every call into a > > windows message, anytime you enter a modal message pump from the > > main STA another thread can renter the STA's objects -- and there > > is *no* way to effectively lock them out as one would normally do > > in an MTA app because it's the same physical thread, even though > > it is a different "logical" thread (i.e. it would own any critical > > section objects already, etc). This behavior is entirely unpredictable > > and unavoidable, because you have no control over the internals > > IMessageFilter can't solve the problem, but i'm getting off track) > > of modal message pumps (which exist in several apis). > > Actually, we faced this problem at Artisoft, when we implemented > soft updates in 1995, after we ported the Heidemann VFS stacking > framework and the Berkeley FFS to Windows95 (well before soft > updates were supported on any BSD -- Matt Day did most of the > work on the Soft Updates implementation). > > The trick is that you can't use a semaphore, you have to use a > mutual exclusion. This bit us when the timer thread would fire > for the kernel thread we had running the soft updates update > clock, since it would basically grab any thread context to run > on (like FreeBSD has been proposing to do for interrupt threads). > > If you use the real mutual exclusion primitives, rather than > the semaphore calls, it's not a problem. For this to work, > you have to "OpenDriver" a VXD that implements the exlusion > mechanism using the kernel primitives. It's really pretty > trivial, if you have the DDK license, which any (at the time) > "MSDN Level 2" or better developer network member had (it was > a matter of paying for the SDK's and DDK's, in other words). Maybe i'm not understanding the above, but it sounds like you're just suggesting using the in-kernel locking stuff through a new api provided by a module. I don't see how this would solve the problem as it is the same thread: Thread A in main STA spawns a worker thread B Thread B Coinits multi A and B do a lame dance with a HGLOBAL istream to marshal an interface pointer over so B can call back when it is done with the work. A enters a modal dialog or message box B calls a proxy object which makes a win32 message and posts it to thread A's "Com window" message queue A gets the message and executes the specified method now no matter how you try to lock anything all you can do is have A return. It can't wait on the mutex for itself to finish, no matter what kind of mutexes you're using. This of course *could* lead to A coming back from a modal message loop with a bunch of stuff completely changed. In legacy code that isn't written with this in mind (or with reentrency in mind in general) problems could result (and legacy code is one the major uses of the STA (ms also suggests using it for threads which display UI). > > OTOH if you put stuff into the MTA and try to access other pieces > > in an STA which may call back into it (the mta), win32 will actually > > spawn a new thread for every method call back into the MTA. So > > that's gross, but it's worse than just gross: because this is a > > differen't physical thread (but the same "logical" thread, if you > > take my meaning) it can't recurse on mutexes. > > You never want recursion on mutexes. If your code recurses on > mutexes, it's broken, unless you have explicit recursion counting > so that you know it's happening. With "context stealing", there > is really no way to make provably correct code, if you permit > mutex recursion. So, actually, I would blame your code, not the > ViPER framework. The win32 mutex objects all explicitly support recursion. CRITICAL_SECTION objects have a recursion count for exactly this, etc. I don't see what's wrong with recursing on mutexes... it's a fairly common practice in "OO" COM code to have a coclass with a lock member and just protect around functions which need access to other members. How would you propose doing that when the object can't know if one of the functions is going to reenter the object somewhere else? Certainly, regardless of whether or not recursing on mutexes is kosher, the creation of a new thread for each method call across the appartments is quite lame. > > I don't see why the win32 people couldn't have just done their > > component thing without regard to threading, and let individual > > app/component writers deal with it. It's just trying to solve too > > many (nonexistant) problems with one architecture (for more of this > > see their new COR/CLR/.NET (whatever it's called this week) replacement > > for COM+). [ ... ] > In the free-threading case, there was an attempt to make the API > compatible between NT and Windows 95/98. For that to work, the > marshalling ("CoCreateFreeThreadedMarshaller()") was required, > since the data may be in a different address space, and that's > what enabled DCOM ("COM+" as you've called it). The free threaded marshaller is just an implementation of IMarshal which doesn't. The only reason it exists is because marshalling is slow and stupid for in proc stuff. The ftm is also relatively rarely used, because in order for an object to safely use it, all interface pointers it internally holds have to also use the ftm implementation of IMarshall. COM+ is just Yet Another Renaming of COM by MS. It's the same thing as COM; DCOM is a subset of the overal label. Furthermore, in reality it is quite rare to use com without knowing if something is in a different adress space, or even a different threading model. > What Apartment model threading buys you is the ability to > serialize requests into an otherwise unsafe legacy inteface, but this isn't actually true if the legacy code uses any apis which enter modal message pumps (i.e. message box, dialogs, etc). Furthermore it would be better to forward port the old interfaces (or perferably provide new thread safe versions) than to add layers of cruft. > using a simple to write wrapper around the Thunk entry points. > Rental model threading permits the use of local globals, so > long as they aren't used simultaneously (in the FreeBSD world, Rental model threading was never implemented by MS. In win2k they released a new "neutral appartment", which is similar to the old RTA idea, but differs in some significant ways. > this would be like implementing the interface "x_r()" via a > set of locking primitives and a call to "x()"). Again, it > permits a certain level of backward compatability, and, if the > code is written correcly, it can attempt to set freethreding, > fail to do so, and continue to run (in a degraded peroformance > mode) successfully. I don't follow this about freethreading. [ ... ] > Similarly, all of the "x" and "x_r" versions of routines could > have been resolved via "rental model", without having to introduce > a new API. For each instance of a thread, there would be a > late-bound allocation of a thread specific "global" context, > and the APIs would "just work" without all the glue and kludgery > that we see today. The contexts would be freed on "thread > detach", so there would be no memory leak. I'm not sure what this (and some omitted above it) is about either: com threading appartments don't provide the thread detach entry -- that's just part of the way libraries work in win32. What would be nicer though for various _r types of things (and this may well be what is done when neccesary; I'm not too familiar with the stuff) is to "late" allocate any per thread data needed as you suggested, and then use an atexit()-style function which would get called when the thread is shut down. I dunno pthreads very well, but there may even already be such a call? > Say what you will about them, they thought a number of these > issues out, while UNIX has been sitting on it's academic laurels > and doing nothing. I give MS credit where it is due, but one thing I don't give them credit for is "thinking things out" (I.e. design). Apparetment models exist as a lame attempted hack to allow older OLE stuff to work with newer things. It does it poorly because it was poorly designed, and has aged poorly (much like the rest of their API). -- Jordan DeLong fracture@allusion.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 23: 0:19 2002 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 09B6C37B400 for ; Tue, 16 Jul 2002 23:00:02 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63AE043E42 for ; Tue, 16 Jul 2002 23:00:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0588.cvx22-bradley.dialup.earthlink.net ([209.179.200.78] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17Uhql-0006Bk-00; Tue, 16 Jul 2002 22:59:47 -0700 Message-ID: <3D3507A1.A166072D@mindspring.com> Date: Tue, 16 Jul 2002 22:58:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jordan DeLong Cc: Taavi Talvik , freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> <20020717005629.GA42607@allusion.net> <3D34DD99.11FF8526@mindspring.com> <20020717042724.GA45349@allusion.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jordan DeLong wrote: > Thread A in main STA spawns a worker thread B > Thread B Coinits multi > A and B do a lame dance with a HGLOBAL istream to marshal > an interface pointer over so B can call back when > it is done with the work. > A enters a modal dialog or message box > B calls a proxy object which makes a win32 message and > posts it to thread A's "Com window" message queue > A gets the message and executes the specified method > now no matter how you try to lock anything all you can do is > have A return. It can't wait on the mutex for itself to finish, > no matter what kind of mutexes you're using. > > This of course *could* lead to A coming back from a modal message > loop with a bunch of stuff completely changed. In legacy code that > isn't written with this in mind (or with reentrency in mind in > general) problems could result (and legacy code is one the major > uses of the STA (ms also suggests using it for threads which display > UI). I'd argue that with legacy code, this wouldn't be an issue, and B wouldn't be talking to a proxy object because legacy code would not be doing that. 8-). But assuming it did, I'd call this an application bug, since the callback execution is not required to occur synchronously; in fact, the application should be filtering the execution as if it were a totally seperate context. The bug is in the lack of masking. You can cause this same bug in UNIX using System V IPC by not passing a specific "msgtyp" value to msgrcv(2), thereby receiving messages outside of the intended context (i.e. in state zero, receive on A,B, or C; instate 1, receive only Q, R, or S, etc.). > The win32 mutex objects all explicitly support recursion. > CRITICAL_SECTION objects have a recursion count for exactly this, > etc. > > I don't see what's wrong with recursing on mutexes... it's a fairly > common practice in "OO" COM code to have a coclass with a lock > member and just protect around functions which need access to other > members. How would you propose doing that when the object can't > know if one of the functions is going to reenter the object somewhere > else? Design the code so that it doesn't need it. If you don't violate call order layering rules, it never becomes an issue; you really have to wonder why you are reentring code on the same thread: what is it that you need to enter it to have it do that you could have done before, but failed to do, for no good reason? You're really mixing programming models here; you need to decide if you are protecting code, or protecting data -- *one* or the *other* -- and then stick with it, instead of bouncing off the walls. > Certainly, regardless of whether or not recursing on mutexes is > kosher, the creation of a new thread for each method call across > the appartments is quite lame. It's not really necessary, either. In the sample code that comes with their SDK, e.g. the POP3 server, Microsoft creates a pool of threads, rather than creating and destoring one per call. I really don't know who programs like you are suggesting. > The free threaded marshaller is just an implementation of IMarshal > which doesn't. The only reason it exists is because marshalling is > slow and stupid for in proc stuff. The ftm is also relatively rarely > used, because in order for an object to safely use it, all interface > pointers it internally holds have to also use the ftm implementation > of IMarshall. Or you don't connect things with pointers all over the place; the point of OO programming is to limit the object relationships to those which are necessary to solve the problem... and no more. 8-). > COM+ is just Yet Another Renaming of COM by MS. It's the same thing > as COM; DCOM is a subset of the overal label. D = Distributed. "Subset" is a matter of definition. COM has a subset of the functionality of DCOM, in that DCOM can do everything COM does *plus* do it remotely. DCOM is only a subset if you look at it from an interface persepctive: it implements the COM API, but it's not the sum total of code that implements the COM API; but that's "implements" as in "an implementation class", not as in "a part of the whole". > Furthermore, in reality it is quite rare to use com without knowing > if something is in a different adress space, or even a different > threading model. This is practice; it wasn't intended by design. One problem is that programmers insisted on breaking up modules in such a way that the inter-module latency made a significant difference to the overall performance. That's bad coding on their part. Another problem is that there was never a mechanism whereby a programmer could say "I don't give a damn where this functionality comes from, just call it and have it be there when that happens" (hence my earlier reference to SLPv2; Salutation also fits the bill, FWIW; Microsoft never deployed either). > > What Apartment model threading buys you is the ability to > > serialize requests into an otherwise unsafe legacy inteface, > > but this isn't actually true if the legacy code uses any apis > which enter modal message pumps (i.e. message box, dialogs, etc). I never care about reentring GUI components; I can only have one modal dialog pending at one time, and I can only be interacting with a single event source (human being) at a time, anyway. Only badly written code ever has a problem with this. > Furthermore it would be better to forward port the old interfaces > (or perferably provide new thread safe versions) than to add > layers of cruft. Sure. And when you can figure out how to get people to do this, get FreeBSD to take the resolver out of libc, put it in a seperate "libresolv", and update the code to bind9. It's unreasonable to expect everyone to throw away their investment just because it would be more convenient for you if they were to throw away their investment. It would be more conveninent for me if all system calls took a call context argument, and returned immediately, so I could use my full quantum, and do all sysystem processing asynchornously. It would also be more convenient for me if most of the locking was unnecessary because all of the kernel code had been refactored to align API's on the basis of contention for stall points. It would be nice if I could just legally print money with my printer, any time I needed more. If you are going to wish for the impossible, wish big. 8-). > > using a simple to write wrapper around the Thunk entry points. > > Rental model threading permits the use of local globals, so > > long as they aren't used simultaneously (in the FreeBSD world, > > Rental model threading was never implemented by MS. In win2k they > released a new "neutral appartment", which is similar to the old > RTA idea, but differs in some significant ways. Such as? > > this would be like implementing the interface "x_r()" via a > > set of locking primitives and a call to "x()"). Again, it > > permits a certain level of backward compatability, and, if the > > code is written correcly, it can attempt to set freethreding, > > fail to do so, and continue to run (in a degraded peroformance > > mode) successfully. > > I don't follow this about freethreading. You can't force a non-freethreadable module to operate in a mode where freethreading is required. It will refuse. It's an attribute you set on the COM object. > > Similarly, all of the "x" and "x_r" versions of routines could > > have been resolved via "rental model", without having to introduce > > a new API. For each instance of a thread, there would be a > > late-bound allocation of a thread specific "global" context, > > and the APIs would "just work" without all the glue and kludgery > > that we see today. The contexts would be freed on "thread > > detach", so there would be no memory leak. > > I'm not sure what this (and some omitted above it) is about either: > com threading appartments don't provide the thread detach entry -- > that's just part of the way libraries work in win32. You can use that fact to do useful work related to per-thread: data, not code. > What would be nicer though for various _r types of things (and this > may well be what is done when neccesary; I'm not too familiar with > the stuff) is to "late" allocate any per thread data needed as you > suggested, and then use an atexit()-style function which would get > called when the thread is shut down. I dunno pthreads very well, > but there may even already be such a call? No. Because you can't associate the thread context. You could do this in a really ugly way (and garbage collect it, as you suggest), but it requires getting the thread ID and using it as a hash key into your late-bound object allocation list, so that you reuse a given object with a given thread (very expensive); it also fails to solve the problem, unless you run threaded all the time, since an unthreaded program would not have a thread for which an allocation exists, nor really need to spend the overhead. By doing this on a thread-entry/exit basis, you avoid the case where the application is non-threaded, you avoid the thread identity problem, and you avoid the garbage collection (unless you are a memory vendor, garbage collection is a bad idea; it sucks very much for any embedded system: we're talking ~16M footprint for a JVM -- Kaffee -- and 32M for one that doesn't try as hard to collect -- JDK2). > > Say what you will about them, they thought a number of these > > issues out, while UNIX has been sitting on it's academic laurels > > and doing nothing. > > I give MS credit where it is due, but one thing I don't give them > credit for is "thinking things out" (I.e. design). Apparetment > models exist as a lame attempted hack to allow older OLE stuff to > work with newer things. It does it poorly because it was poorly > designed, and has aged poorly (much like the rest of their API). The problem was not "how do I do this while alienating my existing customer base", it was "how do I do this and maintain compatability with my existing customer base". FreeBSD (and UNIX in general) have done some damn stupid things in the name of legacy systems support; look at POSIX: by rights, a scratch implementation of an OS would "do POSIX right", by implementing it as a user space library on an efficient an orthogonal API that probably looked very little like the POSIX API (maybe kqueue based, maybe whatever...). People who live in glass houses shouldn't throw stones. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Jul 16 23:10:44 2002 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 BCD7637B400 for ; Tue, 16 Jul 2002 23:10:41 -0700 (PDT) Received: from leafy.idv.tw (sw59-154-113.adsl.seed.net.tw [61.59.154.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90BFC43E64 for ; Tue, 16 Jul 2002 23:10:40 -0700 (PDT) (envelope-from leafy@leafy.idv.tw) Received: from leafy.idv.tw (localhost [127.0.0.1]) by leafy.idv.tw (8.12.5/8.12.5) with ESMTP id g6H6AcJj000285 for ; Wed, 17 Jul 2002 14:10:39 +0800 (CST) (envelope-from leafy@leafy.idv.tw) Received: (from leafy@localhost) by leafy.idv.tw (8.12.5/8.12.5/Submit) id g6H6Achs000284 for freebsd-chat@freebsd.org; Wed, 17 Jul 2002 14:10:38 +0800 (CST) Date: Wed, 17 Jul 2002 14:10:38 +0800 From: JY To: freebsd-chat@freebsd.org Subject: Geocrawler archive Message-ID: <20020717061038.GA270@leafy.idv.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, The Geocrawler archive seem to have stopped at July 8th for Freebsd related lists. Has anyone else seen this? Jiawei Ye To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Jul 17 5: 4: 4 2002 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 21FC837B400 for ; Wed, 17 Jul 2002 05:04:02 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-27.dsl.lsan03.pacbell.net [64.165.226.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 252EB43E42 for ; Wed, 17 Jul 2002 05:04:01 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 856D566CFB; Wed, 17 Jul 2002 05:04:00 -0700 (PDT) Date: Wed, 17 Jul 2002 05:04:00 -0700 From: Kris Kennaway To: JY Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Geocrawler archive Message-ID: <20020717120359.GA91562@xor.obsecurity.org> References: <20020717061038.GA270@leafy.idv.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20020717061038.GA270@leafy.idv.tw> User-Agent: Mutt/1.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2002 at 02:10:38PM +0800, JY wrote: > Hi, >=20 > The Geocrawler archive seem to have stopped at July 8th for Freebsd relat= ed lists. Has anyone else seen this? Perhaps you should talk to Geocrawler, since they have nothing to do with the freebsd project. Kris --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9NV0vWry0BWjoQKURAva7AJ9cK9ZGE42YjQEz+m7GbwI+Sss27gCgrW0c obMgHz0aPZSZULZz2Er8tSQ= =RjFA -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Jul 17 14: 6:10 2002 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 ADB3237B400 for ; Wed, 17 Jul 2002 14:06:04 -0700 (PDT) Received: from cs6668125-184.austin.rr.com (cs6668125-184.austin.rr.com [66.68.125.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C0E843E31 for ; Wed, 17 Jul 2002 14:06:03 -0700 (PDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1]) by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id g6HLASIU056709; Wed, 17 Jul 2002 16:10:28 -0500 (CDT) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: (from fracture@localhost) by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id g6HLASmA056708; Wed, 17 Jul 2002 16:10:28 -0500 (CDT) Date: Wed, 17 Jul 2002 16:10:28 -0500 From: Jordan DeLong To: Terry Lambert Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability Message-ID: <20020717211028.GA49636@allusion.net> References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> <20020717005629.GA42607@allusion.net> <3D34DD99.11FF8526@mindspring.com> <20020717042724.GA45349@allusion.net> <3D3507A1.A166072D@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <3D3507A1.A166072D@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Took the OP out of the CC list because he probably doesn't care ;P ] On Tue, Jul 16, 2002 at 10:58:57PM -0700, Terry Lambert wrote: > Jordan DeLong wrote: [ ... ] > > This of course *could* lead to A coming back from a modal message > > loop with a bunch of stuff completely changed. In legacy code that > > isn't written with this in mind (or with reentrency in mind in > > general) problems could result (and legacy code is one the major > > uses of the STA (ms also suggests using it for threads which display > > UI). >=20 > I'd argue that with legacy code, this wouldn't be an issue, and > B wouldn't be talking to a proxy object because legacy code would > not be doing that. 8-). Ahh this is a good point; of course, the STA is supposed to be used in new code from threads which display UI anyway according to MS. [ ... ] > > The win32 mutex objects all explicitly support recursion. > > CRITICAL_SECTION objects have a recursion count for exactly this, > > etc. [ ... ] > You're really mixing programming models here; you need to decide > if you are protecting code, or protecting data -- *one* or the > *other* -- and then stick with it, instead of bouncing off the > walls. Ahh, this is quite possible. I'll have to look into strategies for not recursing on mutexes and such (all the MT coding i've done in the past has (possibly incorrectly) assumed this was O.K. practice). > > Certainly, regardless of whether or not recursing on mutexes is > > kosher, the creation of a new thread for each method call across > > the appartments is quite lame. >=20 > It's not really necessary, either. In the sample code that comes > with their SDK, e.g. the POP3 server, Microsoft creates a pool of > threads, rather than creating and destoring one per call. I > really don't know who programs like you are suggesting. The MS rpc stuff. They could be pooling but not showing the nonactive threads in the debugger of course... Dunno. > > The free threaded marshaller is just an implementation of IMarshal > > which doesn't. The only reason it exists is because marshalling is > > slow and stupid for in proc stuff. The ftm is also relatively rarely > > used, because in order for an object to safely use it, all interface > > pointers it internally holds have to also use the ftm implementation > > of IMarshall. >=20 > Or you don't connect things with pointers all over the place; > the point of OO programming is to limit the object relationships > to those which are necessary to solve the problem... and no more. > 8-). This is probably valid; but the above *is* the reason why so few components use the freethreaded implementation for marshalling. > > COM+ is just Yet Another Renaming of COM by MS. It's the same thing > > as COM; DCOM is a subset of the overal label. >=20 > D =3D Distributed. "Subset" is a matter of definition. COM has > a subset of the functionality of DCOM, in that DCOM can do > everything COM does *plus* do it remotely. DCOM is only a > subset if you look at it from an interface persepctive: it > implements the COM API, but it's not the sum total of code > that implements the COM API; but that's "implements" as in > "an implementation class", not as in "a part of the whole". Erm. COM =3D=3D In proc, Out of Proc (but on the same machine), and Across the network (D) com in the usual parlance... Nowadays COM+ is the rename of it. DCOM is a subcategory of the overall thing. > > Furthermore, in reality it is quite rare to use com without knowing > > if something is in a different adress space, or even a different > > threading model. >=20 > This is practice; it wasn't intended by design. One problem is This is mostly because it was poorly designed. [ ... ] > > > using a simple to write wrapper around the Thunk entry points. > > > Rental model threading permits the use of local globals, so > > > long as they aren't used simultaneously (in the FreeBSD world, > >=20 > > Rental model threading was never implemented by MS. In win2k they > > released a new "neutral appartment", which is similar to the old > > RTA idea, but differs in some significant ways. >=20 > Such as? More than one thread can enter it at a time. The similarity to the old RTA idea is that the NTA doesn't own its own threads, it only owns components. > > > this would be like implementing the interface "x_r()" via a > > > set of locking primitives and a call to "x()"). Again, it > > > permits a certain level of backward compatability, and, if the > > > code is written correcly, it can attempt to set freethreding, > > > fail to do so, and continue to run (in a degraded peroformance > > > mode) successfully. > >=20 > > I don't follow this about freethreading. >=20 > You can't force a non-freethreadable module to operate in a mode > where freethreading is required. It will refuse. It's an attribute > you set on the COM object. Free threading is about marshalling; it's not something that's "attempted" like you seem to think. When you have a proxied interface to an object it *will* do marshalling: It QI's the object for IMarshal and gets back an aggregated object which does the work. This object can be the ftm to circumvent marshalling (it implements the marshaling stuff by not marshalling), or it can be NULL to tell the proxy to use standard marshalling. So I still don't follow your eariler comments... Maybe you are talking about something else? --=20 Jordan DeLong fracture@allusion.net --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9Nd1DDrrilS51AZ8RAmXUAJ0QCPxVnA9jDwD+YdLh1YAtgQ/GKACgx/1x s8LjP7Yva5FekpGlMxPHEv0= =6qfz -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Jul 17 18:37:42 2002 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 4677437B400 for ; Wed, 17 Jul 2002 18:37:40 -0700 (PDT) Received: from leafy.idv.tw (sw59-154-113.adsl.seed.net.tw [61.59.154.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3746D43E3B for ; Wed, 17 Jul 2002 18:37:39 -0700 (PDT) (envelope-from leafy@leafy.idv.tw) Received: from leafy.idv.tw (localhost [127.0.0.1]) by leafy.idv.tw (8.12.5/8.12.5) with ESMTP id g6I1bdJj059635 for ; Thu, 18 Jul 2002 09:37:40 +0800 (CST) (envelope-from leafy@leafy.idv.tw) Received: (from leafy@localhost) by leafy.idv.tw (8.12.5/8.12.5/Submit) id g6I1bdg6059634 for freebsd-chat@FreeBSD.ORG; Thu, 18 Jul 2002 09:37:39 +0800 (CST) Date: Thu, 18 Jul 2002 09:37:39 +0800 From: JY To: freebsd-chat@FreeBSD.ORG Subject: Re: Geocrawler archive Message-ID: <20020718013739.GA59624@leafy.idv.tw> Mail-Followup-To: freebsd-chat@FreeBSD.ORG References: <20020717061038.GA270@leafy.idv.tw> <20020717120359.GA91562@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline In-Reply-To: <20020717120359.GA91562@xor.obsecurity.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jul 17, 2002 at 05:04:00AM -0700, Kris Kennaway wrote: > On Wed, Jul 17, 2002 at 02:10:38PM +0800, JY wrote: > > Hi, > > > > The Geocrawler archive seem to have stopped at July 8th for Freebsd related lists. Has anyone else seen this? > > Perhaps you should talk to Geocrawler, since they have nothing to do > with the freebsd project. > > Kris Hi Kris I brought this up because Geocrawler was mentioned in FreeBSD search page. Wouldn't there be someone who is in touch with Geocrawler on FreeBSD project side? JY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Jul 17 23:13: 5 2002 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 03CF937B40A for ; Wed, 17 Jul 2002 23:13:00 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519A343E3B for ; Wed, 17 Jul 2002 23:12:59 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0300.cvx22-bradley.dialup.earthlink.net ([209.179.199.45] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17V4X1-00050M-00; Wed, 17 Jul 2002 23:12:55 -0700 Message-ID: <3D365C37.ED032A35@mindspring.com> Date: Wed, 17 Jul 2002 23:12:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jordan DeLong Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Linker sets portability References: <20020717014008.Y99892-100000@valu.uninet.ee> <3D34AC52.2D882455@mindspring.com> <20020717005629.GA42607@allusion.net> <3D34DD99.11FF8526@mindspring.com> <20020717042724.GA45349@allusion.net> <3D3507A1.A166072D@mindspring.com> <20020717211028.GA49636@allusion.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jordan DeLong wrote: > > You're really mixing programming models here; you need to decide > > if you are protecting code, or protecting data -- *one* or the > > *other* -- and then stick with it, instead of bouncing off the > > walls. > > Ahh, this is quite possible. I'll have to look into strategies > for not recursing on mutexes and such (all the MT coding i've > done in the past has (possibly incorrectly) assumed this was > O.K. practice). The entire idea of protecting data objects over function call boundaries is really, really broken (unless those calls are "lock" and "unlock" 8-)). If you are going to potect data, it should only be while accessing contents over a short period of time. Effectively, this means that for recursive locks to be needed, you must have figured out some magic way to recurse without making a function call. 8-). > > > Certainly, regardless of whether or not recursing on mutexes is > > > kosher, the creation of a new thread for each method call across > > > the appartments is quite lame. > > > > It's not really necessary, either. In the sample code that comes > > with their SDK, e.g. the POP3 server, Microsoft creates a pool of > > threads, rather than creating and destroying one per call. I > > really don't know who programs like you are suggesting. > > The MS rpc stuff. They could be pooling but not showing the nonactive > threads in the debugger of course... Dunno. The RPC code is broken. Alfred Perlstein has a method of making RPC calls asynchronous using setjmp/longjmp threads which he came up with ("zbthreads"). This is also broken; it basically is an attempt to salvage unsalvageable code for reuse, when, overall, it would in fact be less time consuming to rewrite the code from scratch to permit asynchronus calls. > > > Furthermore, in reality it is quite rare to use com without knowing > > > if something is in a different adress space, or even a different > > > threading model. > > > > This is practice; it wasn't intended by design. One problem is > > This is mostly because it was poorly designed. I think it's because it's poorly used. You don't blame the design of the tool when a tool is misused. We're a very long way from being able to design a gun that can only be fired by its owner, and which will refuse to fire, for example, unless the path of the bullet, including riccochets, will not intersect the body of the owner. It's impossible to child-proof everything. > > > Rental model threading was never implemented by MS. In win2k they > > > released a new "neutral appartment", which is similar to the old > > > RTA idea, but differs in some significant ways. > > > > Such as? > > More than one thread can enter it at a time. The similarity to the > old RTA idea is that the NTA doesn't own its own threads, it only > owns components. Unless you can have more than one thread involved simultaneously, I don't really see the difference; it sounds like a rule that you would be following in the rental model case, anyway. > > You can't force a non-freethreadable module to operate in a mode > > where freethreading is required. It will refuse. It's an attribute > > you set on the COM object. > > Free threading is about marshalling; it's not something that's > "attempted" like you seem to think. When you have a proxied interface > to an object it *will* do marshalling: It QI's the object for > IMarshal and gets back an aggregated object which does the work. > This object can be the ftm to circumvent marshalling (it implements > the marshaling stuff by not marshalling), or it can be NULL to tell > the proxy to use standard marshalling. > > So I still don't follow your eariler comments... Maybe you are > talking about something else? If the interface locks on entry, or queues for handoff to another thread, it doesn't matter how "freethreaded" the caller thinks it is, the operation is going to follow the model for the module in the module. As long as threading is intended to be allowed, the relevant model is enforced. As far as marshalling goes... as I said before, if you are using in proces servers (I've never actually seen external servers used when the component was on the same machine as the calling component), as long as you create the objects prior to creating the threads, you can freely hand the objects back and forth without marshalling; this is an artifact of the way Windows handles address spaces. A newly created thread gets a copy of the mappings for the objects that were instantiated in the address space of the program/thread creating it... it's effectively a copy of the parent address space. It's very like rfork() with address space sharing. The difference is that mappings which are created subsequently to the point the thread is created are not shared, they are per thread address space (in other words, TLS is not TL for objects created early enough). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Jul 18 8:54: 7 2002 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 347A937B400 for ; Thu, 18 Jul 2002 08:54:04 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-27.dsl.lsan03.pacbell.net [64.165.226.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2CF443E42 for ; Thu, 18 Jul 2002 08:54:03 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2EC5C66DDD; Thu, 18 Jul 2002 08:54:03 -0700 (PDT) Date: Thu, 18 Jul 2002 08:54:02 -0700 From: Kris Kennaway To: JY Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Geocrawler archive Message-ID: <20020718155402.GA29611@xor.obsecurity.org> References: <20020717061038.GA270@leafy.idv.tw> <20020717120359.GA91562@xor.obsecurity.org> <20020718013739.GA59624@leafy.idv.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20020718013739.GA59624@leafy.idv.tw> User-Agent: Mutt/1.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 18, 2002 at 09:37:39AM +0800, JY wrote: > I brought this up because Geocrawler was mentioned in FreeBSD search > page. Wouldn't there be someone who is in touch with Geocrawler on > FreeBSD project side? No, I don't believe so. It's a service provided by Geocrawler which is not directly connected to the FreeBSD project. Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9NuSaWry0BWjoQKURAtTqAJ4gJInBUwjzps43B2ObU7zdLYM+ngCfT848 K27Iwce7DLsoOhv0FgjGl54= =AqFk -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Jul 19 5:56:46 2002 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 AB01537B400 for ; Fri, 19 Jul 2002 05:56:43 -0700 (PDT) Received: from EXIC3.lse.ac.uk (exic3.lse.ac.uk [158.143.217.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFACF43E65 for ; Fri, 19 Jul 2002 05:56:42 -0700 (PDT) (envelope-from M.Tzouris@lse.ac.uk) Received: from ExF2.lse.ac.uk ([158.143.216.21]) by EXIC3.lse.ac.uk with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 13:56:41 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: MSc student, needs help from OS contributor! Date: Fri, 19 Jul 2002 13:56:41 +0100 Message-ID: <09EF96A44C0A7A4FB1D51C1B9DBF9B37468483@ExF2.pc.lse.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSc student, needs help from OS contributor! Thread-Index: AcIvI7pWLNDy2UlFRmi8Z5m0gx9l8A== From: "Tzouris,M" To: X-OriginalArrivalTime: 19 Jul 2002 12:56:41.0790 (UTC) FILETIME=[BA6D95E0:01C22F23] Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello everybody, I am an MSc student at the London School of Economics, department of = Information Systems, London, U.K. (http://is.lse.ac.uk) I am currently = writing my summer dissertation (MSc thesis) on Open Source. This is = where I need your help!=20 I have uploaded an online questionnaire = (http://www.lse-students.ac.uk/tzouris/oss/questionnaire.htm ) on the School's site, and I am searching for Open Source contributors = that might be interested in answering it. The questionnaire is designed = in a way that It won't require more than 10 minutes to be answered. If you are a contributor, you are kindly requested to spend 10 minutes = on filling in this questionnaire = http://www.lse-students.ac.uk/tzouris/oss/questionnaire.htm . My MPhil/PhD which is commencing in the upcoming October, will be = based on my current research. So as you can understand your help is = really important to me.=20 Thank you very much in advance for your help, Menelaos. PS: my background: http://www.geocities.com/tzmnlaos=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Menelaos G. Tzouris Graduate Student Department of Information Systems London School of Economics and Political Science To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Jul 19 6: 4:19 2002 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 C4F8837B400 for ; Fri, 19 Jul 2002 06:04:14 -0700 (PDT) Received: from relay5.kornet.net (relay5.kornet.net [211.48.62.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id D37CF43E97 for ; Fri, 19 Jul 2002 06:03:59 -0700 (PDT) (envelope-from ggaggung05@kornet.net) Received: from you6-wz5svlcx64 (61.73.132.20) by relay5.kornet.net; 19 Jul 2002 22:03:55 +0900 Message-ID: <3d380e3c3d4b87c3@relay5.kornet.net> (added by relay5.kornet.net) From: =?ks_c_5601-1987?B?v+y4rsSrteUgyLi/+L+1vvcgxsDA5Q==?= To: chat@freebsd.org Subject: =?ks_c_5601-1987?B?W7GksO1dIGNoYXS01CDA57nMwNa0wiC758C6x7DAuyC15biztM+02S4=?= Date: Fri, 19 Jul 2002 21:11:46 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01C0F11A.93A46C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0217_01C0F11A.93A46C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 v+y4rsSrteUgICAgDQoNCiAgICAgDQogICAgCQkJCQkJILy6uO0gIAkJICDB1rnOte63zyC5 +MijICANCsH3wOUgwPzIrSAgICAgIMjetOvG+SAgCSAgICAgDQogICANCiAgICAgILHNx8/A xyAguN7Az8HWvNK0wiDApbytx87AuyDF68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7raw x9EgwaS6uLW1ILCusO0gIMDWwfYgvsrAvcC7ILngyPy0z7TZLg0KICDAzCBFLW1haWzAuiC5 373FwPy/68DMuOcsIL/4xKEgvsrAuL3HICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rimIMDU t8LHz7+pIMHWvcO46SC1ziC5+CC02b3DILjewM8gIMDMICCwocH2IL7KtbW3zyDHz7DavcC0 z7TZLg0KICAgICAJICC89r3FsMW6ziAgLyByZWZ1c2FsIG9mIHJlY2VpcHQgICAJICAgIAkg IA0KIA0KDQogDQo= ------=_NextPart_000_0217_01C0F11A.93A46C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPFNDUklQVCBsYW5ndWFnZT1qYXZhc2NyaXB0Pg0KPCEtLQ0K ZnVuY3Rpb24gY2xpY2tNb3VzZSgpDQoJew0KCSAgDQoJCWlmICgoZXZlbnQuYnV0dG9uPT0y KSB8fCAoZXZlbnQuYnV0dG9uPT0zKSl7DQoJCQlyZXR1cm4gKGZhbHNlKTsNCgkJfQkNCgl9 DQoJDQoJZnVuY3Rpb24gY2xpY2tLZXkoKQ0KCXsNCgkJaWYoKGV2ZW50LnNoaWZ0S2V5KSAm JiAoZXZlbnQua2V5Q29kZSA9PSAxMjEpKQ0KCQl7CQkNCgkJCXJldHVybiBmYWxzZTsNCgkJ fQkNCgl9DQoJDQoJZnVuY3Rpb24gbm9BY3Rpb24oKXsNCgkJcmV0dXJuIGZhbHNlOw0KCX0N Cg0KZG9jdW1lbnQub25tb3VzZWRvd249Y2xpY2tNb3VzZQ0KZG9jdW1lbnQub25rZXlkb3du PWNsaWNrS2V5DQpkb2N1bWVudC5vbmNvbnRleHRtZW51PW5vQWN0aW9uDQpkb2N1bWVudC5v bmRyYWdzdGFydD1ub0FjdGlvbg0KZG9jdW1lbnQub25zZWxlY3RzdGFydD1ub0FjdGlvbg0K Ly8tLT4NCjwvU0NSSVBUPg0KDQoNCg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT6/7LiuxKu1 5SAgPC90aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgdGV4dD0i YmxhY2siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiPg0KPHRhYmxl IGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1ODki IGhlaWdodD0iOTIiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9 ImJsYWNrIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNTkyIiBjb2xzcGFuPSIy Ij4NCiAgICAgICAgICAgIDxwPjxpbWcgc3JjPSJodHRwOi8vd3d3Lml5ZXNjYXJkLmNvbS9p bWFnZS90b3BfNy5naWYiIHdpZHRoPSI1OTciIGhlaWdodD0iOTIiIGJvcmRlcj0iMCI+PC9w Pg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lk dGg9IjU5MiIgY29sc3Bhbj0iMiI+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvYm90dG9tNi5naWYiIHdp ZHRoPSI1OTciIGhlaWdodD0iMjExIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4N CiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODkiIGNvbHNwYW49 IjIiPg0KCQkJCQk8Zm9ybSBuYW1lPSJtYWlsZnJtIiBhY3Rpb249Imh0dHA6Ly93d3cuaXdv b3JpY2FyZC5jb20vbWFpbC9pbnNlcnQxLmFzcCIgbWV0aG9kPSJwb3N0IiA+CQ0KICAgICAg ICAgICAgPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtaW5kZW50Oi0xOyBsaW5lLWhl aWdodDowOyBtYXJnaW46MDsiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij68urjt PC9mb250Pjxmb250IHNpemU9IjIiPiAgDQogICAgICAgICAgPC9mb250PjxpbnB1dCB0eXBl PSJ0ZXh0IiBuYW1lPSJuYW1lIiBzaXplPSI2Ij4NCgkJICAmbmJzcDs8Zm9udCBzaXplPSIy IiBjb2xvcj0iIzY2NjY2NiI+wda5zrXut88gufjIoyA8L2ZvbnQ+PGlucHV0IHR5cGU9InRl eHQiIG5hbWU9Imp1bWluIiBzaXplPSIxNCIgbWF4bGVuZ3RoPSIxNCI+DQogICAgICAgICAg PGJyPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij7B98DlIMD8yK0gIA0KICAgICAg ICAgIDwvZm9udD48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0idGVsbnVtIiBzaXplPSIxMyI+ DQogICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2 NjY2NjYiPsjetOvG+SA8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PGlucHV0IHR5cGU9InRleHQi IG5hbWU9ImhhbmRudW0iIHNpemU9IjE1Ij4NCiAgICAgICAgICA8L2ZvbnQ+PGlucHV0IHR5 cGU9InN1Ym1pdCIgbmFtZT0iU3VibWl0MiIgdmFsdWU9Ir3Fw7siPiA8L2Zvcm0+DQoNCgkN CiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRo PSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6 Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50MS5naWYiIHdpZHRoPSIyOTQiIGhlaWdo dD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdp ZHRoPSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0 dHA6Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50Mi5naWYiIHdpZHRoPSIyOTQiIGhl aWdodD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1OTIiIGNvbHNwYW49IjIiPg0KICAgICAg ICAgICAgPHAgYWxpZ249ImxlZnQiPiZuYnNwOzxmb250IHNpemU9IjIiIGZhY2U9IrG8uLIi IGNvbG9yPSIjNjY2NjY2Ij6xzcfPwMcgDQogICAgICAgICAgICC43sDPwda80rTCIMClvK3H zsC7IMXrx9ggvPbB/cfRILDNwMy45ywgsde/3L+hIL7utrDH0SDBpLq4tbUgsK6w7SANCiAg ICAgICAgICAgIMDWwfYgvsrAvcC7ILngyPy0z7TZLjxicj4gJm5ic3A7wMwgRS1tYWlswLog ud+9xcD8v+vAzLjnLCC/+MShIL7KwLi9xyANCiAgICAgICAgICAgILDmv+wgvsa3oSDDor+h ILjewM/B1rzSuKYgwNS3wsfPv6kgwda9w7jpILXOILn4ILTZvcMguN7AzyAmbmJzcDvAzCAN CiAgICAgICAgICAgILChwfYgvsq1tbfPIMfPsNq9wLTPtNkuPC9mb250PjwvcD4NCiAgICAg ICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODki IGNvbHNwYW49IjIiPg0KICA8Zm9ybSBuYW1lPSJtYWlsZnJtMiIgYWN0aW9uPSJodHRwOi8v d3d3Lml3b29yaWNhcmQuY29tL21haWwvbm8uYXNwIiBtZXRob2Q9InBvc3QiID4gIAkgIA0K ICAgICAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tbGVmdDow OyI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2NjY2NjYiPrz2vcWwxbrOIA0KICAgICAgICAg ICAgICAgIC8gcmVmdXNhbCBvZiByZWNlaXB0PC9mb250PiANCiAgICAgICAgICA8aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjI1Ij4NCiAgICAgICAgICA8aW5wdXQg dHlwZT0ic3VibWl0IiBuYW1lPSJTdWJtaXQiIHZhbHVlPSJFTlRFUiI+PC9mb3JtPgkNCiAg ICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1 ODkiIGNvbHNwYW49IjIiPg0KCTxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTsgbWFyZ2luLXJpZ2h0OjA7IG1hcmdpbi1sZWZ0OjA7Ij48aW1nIHNyYz0iaHR0cDov L3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvZjMuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYw IiBib3JkZXI9IjAiIGFsaWduPSJtaWRkbGUiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj4gICAg ICAgIDwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQo8cD4mbmJzcDs8L3A+DQo8cD4mbmJz cDs8L3A+DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg0K ------=_NextPart_000_0217_01C0F11A.93A46C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Jul 19 7:17:38 2002 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 5194337B400 for ; Fri, 19 Jul 2002 07:17:34 -0700 (PDT) Received: from relay3.kornet.net (relay3.kornet.net [211.48.62.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B1A43E4A for ; Fri, 19 Jul 2002 07:17:33 -0700 (PDT) (envelope-from ggaggung14@kornet.net) Received: from you14-7tvw5pot5 (61.73.15.121) by relay3.kornet.net; 19 Jul 2002 23:17:28 +0900 Message-ID: <3d381f7b3d3f87cd@relay3.kornet.net> (added by relay3.kornet.net) From: =?ks_c_5601-1987?B?v+y4rsSrteUgyLi/+L+1vvcgxsDA5Q==?= To: chat@freebsd.org Subject: =?ks_c_5601-1987?B?W7GksO1dIGNoYXS01CDA57nMwNa0wiC758C6x7DAuyC15biztM+02S4=?= Date: Fri, 19 Jul 2002 22:22:09 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0227_01C0F22A.93A09C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0227_01C0F22A.93A09C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 v+y4rsSrteUgICAgDQoNCiAgICAgDQogICAgCQkJCQkJILy6uO0gIAkJICDB1rnOte63zyC5 +MijICANCsH3wOUgwPzIrSAgICAgIMjetOvG+SAgCSAgICAgDQogICANCiAgICAgILHNx8/A xyAguN7Az8HWvNK0wiDApbytx87AuyDF68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7raw x9EgwaS6uLW1ILCusO0gIMDWwfYgvsrAvcC7ILngyPy0z7TZLg0KICDAzCBFLW1haWzAuiC5 373FwPy/68DMuOcsIL/4xKEgvsrAuL3HICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rimIMDU t8LHz7+pIMHWvcO46SC1ziC5+CC02b3DILjewM8gIMDMICCwocH2IL7KtbW3zyDHz7DavcC0 z7TZLg0KICAgICAJICC89r3FsMW6ziAgLyByZWZ1c2FsIG9mIHJlY2VpcHQgICAJICAgIAkg IA0KIA0KDQogDQo= ------=_NextPart_000_0227_01C0F22A.93A09C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPFNDUklQVCBsYW5ndWFnZT1qYXZhc2NyaXB0Pg0KPCEtLQ0K ZnVuY3Rpb24gY2xpY2tNb3VzZSgpDQoJew0KCSAgDQoJCWlmICgoZXZlbnQuYnV0dG9uPT0y KSB8fCAoZXZlbnQuYnV0dG9uPT0zKSl7DQoJCQlyZXR1cm4gKGZhbHNlKTsNCgkJfQkNCgl9 DQoJDQoJZnVuY3Rpb24gY2xpY2tLZXkoKQ0KCXsNCgkJaWYoKGV2ZW50LnNoaWZ0S2V5KSAm JiAoZXZlbnQua2V5Q29kZSA9PSAxMjEpKQ0KCQl7CQkNCgkJCXJldHVybiBmYWxzZTsNCgkJ fQkNCgl9DQoJDQoJZnVuY3Rpb24gbm9BY3Rpb24oKXsNCgkJcmV0dXJuIGZhbHNlOw0KCX0N Cg0KZG9jdW1lbnQub25tb3VzZWRvd249Y2xpY2tNb3VzZQ0KZG9jdW1lbnQub25rZXlkb3du PWNsaWNrS2V5DQpkb2N1bWVudC5vbmNvbnRleHRtZW51PW5vQWN0aW9uDQpkb2N1bWVudC5v bmRyYWdzdGFydD1ub0FjdGlvbg0KZG9jdW1lbnQub25zZWxlY3RzdGFydD1ub0FjdGlvbg0K Ly8tLT4NCjwvU0NSSVBUPg0KDQoNCg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT6/7LiuxKu1 5SAgPC90aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgdGV4dD0i YmxhY2siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiPg0KPHRhYmxl IGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1ODki IGhlaWdodD0iOTIiIGJvcmRlcmNvbG9yZGFyaz0id2hpdGUiIGJvcmRlcmNvbG9ybGlnaHQ9 ImJsYWNrIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iNTkyIiBjb2xzcGFuPSIy Ij4NCiAgICAgICAgICAgIDxwPjxpbWcgc3JjPSJodHRwOi8vd3d3Lml5ZXNjYXJkLmNvbS9p bWFnZS90b3BfNy5naWYiIHdpZHRoPSI1OTciIGhlaWdodD0iOTIiIGJvcmRlcj0iMCI+PC9w Pg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lk dGg9IjU5MiIgY29sc3Bhbj0iMiI+DQogICAgICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvYm90dG9tNi5naWYiIHdp ZHRoPSI1OTciIGhlaWdodD0iMjExIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4N CiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODkiIGNvbHNwYW49 IjIiPg0KCQkJCQk8Zm9ybSBuYW1lPSJtYWlsZnJtIiBhY3Rpb249Imh0dHA6Ly93d3cuaXdv b3JpY2FyZC5jb20vbWFpbC9pbnNlcnQxLmFzcCIgbWV0aG9kPSJwb3N0IiA+CQ0KICAgICAg ICAgICAgPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtaW5kZW50Oi0xOyBsaW5lLWhl aWdodDowOyBtYXJnaW46MDsiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij68urjt PC9mb250Pjxmb250IHNpemU9IjIiPiAgDQogICAgICAgICAgPC9mb250PjxpbnB1dCB0eXBl PSJ0ZXh0IiBuYW1lPSJuYW1lIiBzaXplPSI2Ij4NCgkJICAmbmJzcDs8Zm9udCBzaXplPSIy IiBjb2xvcj0iIzY2NjY2NiI+wda5zrXut88gufjIoyA8L2ZvbnQ+PGlucHV0IHR5cGU9InRl eHQiIG5hbWU9Imp1bWluIiBzaXplPSIxNCIgbWF4bGVuZ3RoPSIxNCI+DQogICAgICAgICAg PGJyPjxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij7B98DlIMD8yK0gIA0KICAgICAg ICAgIDwvZm9udD48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0idGVsbnVtIiBzaXplPSIxMyI+ DQogICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2 NjY2NjYiPsjetOvG+SA8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PGlucHV0IHR5cGU9InRleHQi IG5hbWU9ImhhbmRudW0iIHNpemU9IjE1Ij4NCiAgICAgICAgICA8L2ZvbnQ+PGlucHV0IHR5 cGU9InN1Ym1pdCIgbmFtZT0iU3VibWl0MiIgdmFsdWU9Ir3Fw7siPiA8L2Zvcm0+DQoNCgkN CiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRo PSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6 Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50MS5naWYiIHdpZHRoPSIyOTQiIGhlaWdo dD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHdp ZHRoPSIyOTQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0 dHA6Ly93d3cuaXllc2NhcmQuY29tL2ltYWdlL2V2ZW50Mi5naWYiIHdpZHRoPSIyOTQiIGhl aWdodD0iMjAwIiBib3JkZXI9IjAiPjwvcD4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1OTIiIGNvbHNwYW49IjIiPg0KICAgICAg ICAgICAgPHAgYWxpZ249ImxlZnQiPiZuYnNwOzxmb250IHNpemU9IjIiIGZhY2U9IrG8uLIi IGNvbG9yPSIjNjY2NjY2Ij6xzcfPwMcgDQogICAgICAgICAgICC43sDPwda80rTCIMClvK3H zsC7IMXrx9ggvPbB/cfRILDNwMy45ywgsde/3L+hIL7utrDH0SDBpLq4tbUgsK6w7SANCiAg ICAgICAgICAgIMDWwfYgvsrAvcC7ILngyPy0z7TZLjxicj4gJm5ic3A7wMwgRS1tYWlswLog ud+9xcD8v+vAzLjnLCC/+MShIL7KwLi9xyANCiAgICAgICAgICAgILDmv+wgvsa3oSDDor+h ILjewM/B1rzSuKYgwNS3wsfPv6kgwda9w7jpILXOILn4ILTZvcMguN7AzyAmbmJzcDvAzCAN CiAgICAgICAgICAgILChwfYgvsq1tbfPIMfPsNq9wLTPtNkuPC9mb250PjwvcD4NCiAgICAg ICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1ODki IGNvbHNwYW49IjIiPg0KICA8Zm9ybSBuYW1lPSJtYWlsZnJtMiIgYWN0aW9uPSJodHRwOi8v d3d3Lml3b29yaWNhcmQuY29tL21haWwvbm8uYXNwIiBtZXRob2Q9InBvc3QiID4gIAkgIA0K ICAgICAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tbGVmdDow OyI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2NjY2NjYiPrz2vcWwxbrOIA0KICAgICAgICAg ICAgICAgIC8gcmVmdXNhbCBvZiByZWNlaXB0PC9mb250PiANCiAgICAgICAgICA8aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjI1Ij4NCiAgICAgICAgICA8aW5wdXQg dHlwZT0ic3VibWl0IiBuYW1lPSJTdWJtaXQiIHZhbHVlPSJFTlRFUiI+PC9mb3JtPgkNCiAg ICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1 ODkiIGNvbHNwYW49IjIiPg0KCTxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTsgbWFyZ2luLXJpZ2h0OjA7IG1hcmdpbi1sZWZ0OjA7Ij48aW1nIHNyYz0iaHR0cDov L3d3dy5peWVzY2FyZC5jb20vaW1hZ2UvZjMuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYw IiBib3JkZXI9IjAiIGFsaWduPSJtaWRkbGUiIHZzcGFjZT0iMCIgaHNwYWNlPSIwIj4gICAg ICAgIDwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQo8cD4mbmJzcDs8L3A+DQo8cD4mbmJz cDs8L3A+DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg0K ------=_NextPart_000_0227_01C0F22A.93A09C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Jul 19 13:42:10 2002 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 3993837B400 for ; Fri, 19 Jul 2002 13:42:09 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CFDA43E3B for ; Fri, 19 Jul 2002 13:42:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0472.cvx22-bradley.dialup.earthlink.net ([209.179.199.217] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17VeZc-00018I-00; Fri, 19 Jul 2002 13:42:00 -0700 Message-ID: <3D38796A.2F0E3FF5@mindspring.com> Date: Fri, 19 Jul 2002 13:41:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Tzouris,M" Cc: freebsd-chat@FreeBSD.org Subject: Re: MSc student, needs help from OS contributor! References: <09EF96A44C0A7A4FB1D51C1B9DBF9B37468483@ExF2.pc.lse.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Tzouris,M" wrote: > I have uploaded an online questionnaire (http://www.lse-students.ac.uk/tzouris/oss/questionnaire.htm > ) on the School's site, and I am searching for Open Source contributors that might be interested in answering it. The questionnaire is designed in a way that It won't require more than 10 minutes to be answered. > > If you are a contributor, you are kindly requested to spend 10 minutes on filling in this questionnaire http://www.lse-students.ac.uk/tzouris/oss/questionnaire.htm > . My MPhil/PhD which is commencing in the upcoming October, will be based on my current research. So as you can understand your help is really important to me. Some of your questions are badly formed. Question #9 is the most aggregious of these, in that it assumes two reasons for participation, and forces the answerer to place themselves into one of the two available categories. Several other questions also contain false dichotomies and assumptions, and therefore have no correct answer (e.g. section B, the 5-6/7-8 split and 11's mistaken assumption of motivation). I realize that the intent of an economics student is to define things in terms of compensation for effort, but assuming a direct reward is a bit naieve (e.g. "a reward is to gt you to do something you would not otherwise do, except for the reward" -- George Carlin). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message