From owner-freebsd-advocacy Mon Aug 6 6:35:21 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from relay2.kornet.net (unknown [211.48.62.162]) by hub.freebsd.org (Postfix) with ESMTP id F02AF37B401; Mon, 6 Aug 2001 06:32:52 -0700 (PDT) (envelope-from clubfriend@clubfriend.com) Received: from bown112 (211.38.171.177) by relay2.kornet.net; 6 Aug 2001 22:32:55 +0900 Message-ID: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> Reply-To: "Youn, Roy" From: "Youn, Roy" To: =?ks_c_5601-1987?B?wK/H0MC7wdi68cfPtMK60LKy?= Subject: =?ks_c_5601-1987?B?W8irurhdwK/H0Mb4xbq96sDPISEhyK69x8fRwbawxyEhtbXA/MfP?= =?ks_c_5601-1987?B?vLy/5CEhISE=?= Date: Mon, 6 Aug 2001 22:30:35 +0900 Organization: =?ks_c_5601-1987?B?x8G3o7XlIMCvx9C/+A==?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C11EC7.693216A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-advocacy@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_0063_01C11EC7.693216A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ICAgICAgICAgICANCg0KDQogICAgICAgICAgICC+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0 z7TZLg0KICAgICAgICAgICAgursguN7Az8C6IMiruri43sDPwNS0z7TZLiDH47b0vvjAzCC43sDP wLsgurizu7XluK6w1CC1yCDBob+hILTrx9ggwcu828fVtM+02S4gDQoNCiAgICAgICAgICAgICog sc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/obytIML8wbbHz7+0vcC0z7TZ Lg0KDQoNCiAgICAgICAgICAgIL+1vu6woSC09SDAzLvzwLoguaux4rChIL7GtNEgx8q89sD7wM4g v+S80rfOILTZsKG/wLTCIMDMIL3DtOu/oSDFq7W3IL7ItenAzLDttbUgx9i/3L+svPa/zSDAr7e0 ILnos7a/qcfgse7B9iC02bPgv8MgvPYgwNa0wrHiyLiwoSDA1r7uvK0gvNKwsyDH1bTPtNkuDQog ICAgICAgICAgICCx17DNtbUgwaTF67+1vu64piC56L/vILz2IMDWtMIgv7WxuSC3sbT4wMcgTE9O RE9OIEVOR0xJU0ggU0NIT09MIL+hvK0gwNS0z7TZLg0KDQogICAgICAgICAgICC6zrTjIL74tMIg sKGw3cC4t84gw+K538fPsO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bim ILn6vPYgwNa9wLTPtNkuILbHx9Egv6y89rChILOhs6q46SCwobHuv+4gx8G2+726LCDAzMXCuK4g te4gv6m3ryDAr7e0s6q287fOILnos7a/qcfgwLsgtrCzryC89iDA1r3AtM+02S4NCg0KDQogICAg ICAgICAgICAgICAgICDH4LvnwM/BpCA0wvcgOS8zIDogMjAguO0gwaS/+CAoMrjtv6nArykgDQog ICAgICAgICAgICAgICAgICAoMjAwMbPiKSA1wvcgOS8yNCA6IDIwILjtIMGkv/ggIA0KICAgICAg ICAgICAgICAgICAgICA2wvcgMTAvMTkgOiAxNSC47SDBpL/4ICi4trCoKSANCiAgICAgICAgICAg ICAgICAgICAgN8L3IDExLzQgOiAxNSC47SDBpL/4IA0KDQogICAgICAgICAgICDC/LChuvEgOiC/ rLz2IDaws7/5seLB2CAzODAguLi/+CAvIL+svPYgMbPiILHiwdggNDQwILi4v/ggKMSrteUgsOHB piCwobTJKSAoKiogv6y89rHisKMgv6zA5bChtMkpDQogICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICDC/LChuvEgxvfH1LO7v6ogOiC/1bq5IMfXsPixxyAoNrCzv/mwoyks ILz2vve34SDA/L7XLCA0wdYgvPe52rrxICgywM4xvccpLCC89rzTt+EsIMPiud/A/CC80r7nsbPA sCwgseKz5CC6ubTrLCC/qcfgwNogurjH6Cwgx/bB9rChwMy15SAosPjH17nMxsMsILz3vNIsIMfQ sbMsIL7GuKO52cDMxq4pIA0KICAgICAgICAgICAgKrvzseIgsd2+18C6IMfQuvEgwPy+1yC51yDA z8O8IMb3x9TAzLbzILT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOcgv7m78yC7/ciwuvG/6yAo vPe9xLrxLCCxs8XrLCC/67W3KcC6IL/5IDcwuLi/+CC8scC4t84gvsa4o7nZwMzGriC89sDUwLi3 ziDD5rTnILChtMnH1bTPtNkuIA0KICAgICAgICAgICAgx/bB9iC+xrijudnAzMauIDogxLO8xSwg veG68Swgv6nH4LvnILChwMy15SC51yC757mrwfcsILzux84gvsa4o7nZwMzGriwgvcS05yC6uMG2 te4gDQogICAgICAgICAgICDH9sH2IL7GuKO52cDMxq4gvPbA1CA6IL3DsKO05yDD1sD6IDcsMDAw v/h+MTAsMDAwv/ggICAxwM8gNb3DsKMsIMHWIDXAzyCx2b3DIC0tLSAxsLO/+SDD1sD6ILz2wNQg NzC4uL/4IH4gMTAwuLi/+CANCg0KDQogICAgICAgICAgICDB9r/4IMDasN0gOiAxOLy8IMDMu/Mg s7IsILPgILSpsbizqiCwobTJICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sikNCg0KICAg ICAgICAgICAgwNq8vMfRILvnu/PAuiDIqMbkwMzB9iC55rmuwMyzqiC6u7vnt84gv6y29CDB1r3D uOkgw9a8scC7ILTZx9ggtbW/zSC15biusNq9wLTPtNkuDQogICAgICAgICAgICBodHRwOi8vd3d3 LmNsdWJmcmllbmQuY29tIC8gx8G3o7XlIMCvx9C/+CAwMzEtMzk2LTc5MDUvNg0KDQogICAgICAg ICAgICC9xcO7wLsgv/jHz73DtMK60MC6IMDMsPfAuyDF68fPv6kgvcXDu7ytuKYgud+828fPv6kg wda9w7HiILnZtvi0z7TZLg0KICAgICAgICAgICAgwbax4iC9xcO7wNq0wiC897zSILyxxcPAzLOq IL7GuKO52cDMxq4gvNKws73Dxq/A/MDMIMHWvu4gwf20z7TZLiANCg0KICAgICAgICAgICAgKrq7 IMCvx9C/+MC6IEJDIMSrteW75yC/tbG5v6y89iC788ewIMf5t8K+98O8IMDUtM+02S4NCg0KICAg ICAgICAgICANCiAgICAgDQoNCg== ------=_NextPart_000_0063_01C11EC7.693216A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFRBQkxF IGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD01MDAgYm9yZGVyPTE+DQogIDxUQk9E WT4NCiAgPFRSPg0KICAgIDxURD4NCiAgICAgIDxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRk aW5nPTAgd2lkdGg9NTAwIGJvcmRlcj0wPg0KICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUj4N CiAgICAgICAgICA8VEQgd2lkdGg9NTAwIGhlaWdodD0yNTA+DQogICAgICAgICAgICA8T0JKRUNU IA0KICAgICAgICAgICAgY29kZUJhc2U9aHR0cDovL2Rvd25sb2FkLm1hY3JvbWVkaWEuY29tL3B1 Yi9zaG9ja3dhdmUvY2Ficy9mbGFzaC9zd2ZsYXNoLmNhYiN2ZXJzaW9uPTUsMCwwLDAgDQogICAg ICAgICAgICBjbGFzc2lkPWNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAw MCB3aWR0aD01MDAgDQogICAgICAgICAgICBoZWlnaHQ9MjUwPjxQQVJBTSBOQU1FPSJfY3giIFZB TFVFPSIxMzIyOSI+PFBBUkFNIE5BTUU9Il9jeSIgVkFMVUU9IjY2MTUiPjxQQVJBTSBOQU1FPSJN b3ZpZSIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IlNyYyIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IldNb2RlIiBWQUxVRT0iV2luZG93Ij48UEFSQU0gTkFNRT0iUGxheSIgVkFMVUU9Ii0xIj48UEFS QU0gTkFNRT0iTG9vcCIgVkFMVUU9Ii0xIj48UEFSQU0gTkFNRT0iUXVhbGl0eSIgVkFMVUU9Ikhp Z2giPjxQQVJBTSBOQU1FPSJTQWxpZ24iIFZBTFVFPSIiPjxQQVJBTSBOQU1FPSJNZW51IiBWQUxV RT0iLTEiPjxQQVJBTSBOQU1FPSJCYXNlIiBWQUxVRT0iIj48UEFSQU0gTkFNRT0iU2NhbGUiIFZB TFVFPSJTaG93QWxsIj48UEFSQU0gTkFNRT0iRGV2aWNlRm9udCIgVkFMVUU9IjAiPjxQQVJBTSBO QU1FPSJFbWJlZE1vdmllIiBWQUxVRT0iMCI+PFBBUkFNIE5BTUU9IkJHQ29sb3IiIFZBTFVFPSIi PjxQQVJBTSBOQU1FPSJTV1JlbW90ZSIgVkFMVUU9IiI+PFBBUkFNIE5BTUU9IlN0YWNraW5nIiBW QUxVRT0iYmVsb3ciPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8ZW1iZWQg ICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vsaSw7S5z d2YiIA0KICAgICAgICAgICAgcXVhbGl0eT1oaWdoICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3 YXZlL2Rvd25sb2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0iYXBwbGljYXRpb24veC1z aG9ja3dhdmUtZmxhc2giIA0KICAgICAgICAgICAgd2lkdGg9IjUwMCIgICAgICAgICAgICAgaGVp Z2h0PSIyNTAiPiAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8L2VtYmVk PiAgICAgICAgICAgICAgICAgICAgICAgPC9PQkpFQ1Q+PC9URD48L1RSPg0KICAgICAgICA8VFI+ DQogICAgICAgICAgPFREPg0KICAgICAgICAgICAgPFA+Jm5ic3A7PC9QPg0KICAgICAgICAgICAg PFA+PEZPTlQgc2l6ZT0tMT6+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0z7TZLjxCUj66uyC4 3sDPwLogyKu6uLjewM/A1LTPtNkuIMfjtvS++MDMILjewM/AuyC6uLO7teW4rrDUIA0KICAgICAg ICAgICAgtcggwaG/oSC068fYIMHLvNvH1bTPtNkuIDwvRk9OVD48L1A+DQogICAgICAgICAgICA8 UD48Rk9OVCBzaXplPS0xPiogsc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/ obytIML8wbbHz7+0vcC0z7TZLjwvRk9OVD48L1A+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXpl PS0xPjxCUj6/tb7usKEgtPUgwMy788C6ILmrseKwoSC+xrTRIMfKvPbA+8DOIL/kvNK3ziC02bCh v8C0wiDAzCC9w7Trv6Egxau1tyC+yLXpwMyw7bW1IA0KICAgICAgICAgICAgPEI+PEZPTlQgY29s b3I9IzAwMDA4MD7H2L/cv6y89r/NIMCvt7Qgueiztr+px+A8L0ZPTlQ+PC9CPrHuwfYgtNmz4L/D ILz2IMDWtMKx4si4sKEgwNa+7rytILzSsLMgDQogICAgICAgICAgICDH1bTPtNkuPEJSPrHXsM21 tSDBpMXrv7W+7rimILnov+8gvPYgwNa0wiC/tbG5ILextPjAxyA8Qj48Rk9OVCBjb2xvcj0jMDAw MDgwPkxPTkRPTiANCiAgICAgICAgICAgIEVOR0xJU0ggU0NIT09MPC9GT05UPjwvQj48Rk9OVCBj b2xvcj0jMDAwMDgwPiA8L0ZPTlQ+v6G8rSANCiAgICAgICAgICAgIMDUtM+02S48L0ZPTlQ+PC9Q Pg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT66zrTjIL74tMIgsKGw3cC4t84gw+K538fP sO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bimILn6vPYgwNa9wLTPtNku ILbHx9EgDQogICAgICAgICAgICC/rLz2sKEgs6GzqrjpILChse6/7iDHwbb7vbosIMDMxcK4riC1 7iC/qbevIMCvt7Szqrbzt84gueiztr+px+DAuyC2sLOvILz2IMDWvcC0z7TZLjwvRk9OVD48Rk9O VCANCiAgICAgICAgICAgIHNpemU9LTE+PEJSPjwvRk9OVD48L1A+DQogICAgICAgICAgICA8VEFC TEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSI4MCUiIGJvcmRlcj0wPg0KICAg ICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICA8 VEQgd2lkdGg9IjI3JSI+PEZPTlQgc2l6ZT0tMT7H4LvnwM/BpDwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjTC9yA5LzMgOjwvRk9OVD48 L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjIwILjt IMGkv/ggKDK47b+pwK8pPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRSPg0KICAg ICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj48Rk9OVCBzaXplPS0xPigyMDAxs+IpPC9GT05U PjwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+NcL3 IDkvMjQgOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9O VCBzaXplPS0xPjIwILjtIMGkv/ggPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRS Pg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj4mbmJzcDs8L1REPg0KICAgICAgICAg ICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjbC9yAxMC8xOSA6PC9GT05UPjwv VEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI1MSUiPjxGT05UIHNpemU9LTE+MTUguO0g waS/+CAouLawqCk8L0ZPTlQ+PC9URD48L1RSPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAg ICAgICAgICAgPFREIHdpZHRoPSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFRE IHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+N8L3IDExLzQgOjwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjE1ILjtIA0KICAgICAgICAg ICAgwaS/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxGT05UIHNpemU9LTE+PEJS PsL8sKG68SA6IL+svPYgPEZPTlQgDQogICAgICAgICAgICBjb2xvcj0jZmYwMDAwIHNpemU9Mz48 Qj42sLO/+bHiwdggMzgwILi4v/g8L0I+PC9GT05UPiAvIL+svPYgPEZPTlQgDQogICAgICAgICAg ICBzaXplPTM+PEI+PEZPTlQgY29sb3I9I2ZmMDAwMD4xs+IgseLB2CA0NDAguLi/+DwvRk9OVD48 L0I+IDwvRk9OVD4oxKu15SCw4cGmIA0KICAgICAgICAgICAgsKG0yTxGT05UIGNvbG9yPSMwMDAw ODA+KTwvRk9OVD4gKCoqIL+svPax4rCjIL+swOWwobTJKTxCUj48L0ZPTlQ+DQogICAgICAgICAg ICA8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9 MD4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAg ICAgICAgPFREIHdpZHRoPSIxOCUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdp ZHRoPSI4MiUiPiZuYnNwOzwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQogICAgICAgICAgICA8 VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4N CiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAg ICAgPFREIHZBbGlnbj10b3Agd2lkdGg9IjIyJSI+PEZPTlQgc2l6ZT0tMT7C/LChuvEgxvfH1LO7 v6ogOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNzglIj48Rk9OVCBz aXplPS0xPr/Vurkgx9ew+LHHICg2sLO/+bCjKSwgPEI+PEZPTlQgDQogICAgICAgICAgICAgICAg ICBjb2xvcj0jMDAwMDgwPrz2vve34SDA/L7XPC9GT05UPjwvQj4sIDTB1iC897nauvEgKDLAzjG9 xyksILz2vNO34Swgw+K538D8ILzSvuexs8CwLCANCiAgICAgICAgICAgICAgICAgILHis+Qgurm0 6ywgv6nH4MDaILq4x+gsIMf2wfawocDMteUgKLD4x9e5zMbDLCC897zSLCDH0LGzLCANCiAgICAg ICAgICAgIL7GuKO52cDMxq4pPC9GT05UPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEZPTlQg c2l6ZT0tMT4qu/Ox4iCx3b7XwLogx9C68SDA/L7XILnXIA0KICAgICAgICAgICAgwM/DvCDG98fU wMy28yA8Rk9OVCBjb2xvcj0jMDAwMDgwPjxCPrT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOc8 L0I+PC9GT05UPiC/ubvzILv9yLC68b/rIA0KICAgICAgICAgICAgKLz3vcS68SwgsbPF6ywgv+u1 tynAuiC/+SA3MLi4v/ggvLHAuLfOIL7GuKO52cDMxq4gvPbA1MC4t84gw+a05yCwobTJx9W0z7TZ LiA8L0ZPTlQ+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXplPS0xPsf2wfYgvsa4o7nZwMzGriA6 IMSzvMUsIL3huvEsIL+px+C75yCwocDMteUgudcgu+e5q8H3LCC87sfOIL7GuKO52cDMxq4sIL3E tOcgurjBtrXuIA0KICAgICAgICAgICAgPEJSPsf2wfYgvsa4o7nZwMzGriC89sDUIDogvcOwo7Tn IMPWwPogNywwMDC/+H4xMCwwMDC/+CA8L0ZPTlQ+DQogICAgICAgICAgICA8VEFCTEUgY2VsbFNw YWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4NCiAgICAgICAgICAg ICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAgICAgPFREIHdpZHRo PSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI3MyUiPjxGT05U IHNpemU9LTE+McDPIDW9w7CjLCDB1iA1wM8gsdm9wyAtLS0gMbCzv/kgw9bA+iC89sDUIA0KICAg ICAgICAgICAgICAgICAgNzC4uL/4IH4gMTAwuLi/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48 L1RBQkxFPg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7B9r/4IMDasN0gOiA8Qj48Rk9O VCBjb2xvcj0jMDAwMDgwPjE4vLwgwMy78yCzsiwgs+AgtKmxuLOqIA0KICAgICAgICAgICAgsKG0 yTwvRk9OVD48L0I+ICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sik8L0ZPTlQ+PC9QPg0K ICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7A2ry8x9Egu+e788C6IMioxuTAzMH2ILnmua7A zLOqILq7u+e3ziC/rLb0IMHWvcO46SDD1ryxwLsgtNnH2CC1tb/NIA0KICAgICAgICAgICAgteW4 rrDavcC0z7TZLjxCUj48QSBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20iPmh0dHA6Ly93d3cu Y2x1YmZyaWVuZC5jb20gDQogICAgICAgICAgICA8L0E+LyDHwbejteUgwK/H0L/4IDAzMS0zOTYt NzkwNS82PC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQPjxGT05UIHNpemU9LTE+PEEgDQogICAg ICAgICAgICBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vc3VibWl0LWZyYW1lLmh0bWwiPjxC PjxGT05UIA0KICAgICAgICAgICAgY29sb3I9IzAwMDA4MD69xcO7wLsgv/jHz73DtMK60MC6IMDM sPfAuyDF68fPv6kgvcXDu7ytuKYgud+82zwvRk9OVD48L0I+PC9BPsfPv6kgwda9w7HiIA0KICAg ICAgICAgICAgudm2+LTPtNkuPEJSPsG2seIgvcXDu8DatMIgvPe80iC8scXDwMyzqiC+xrijudnA zMauILzSsLO9w8avwPzAzCDB1r7uIMH9tM+02S4gPC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQ PjxGT05UIHNpemU9LTE+PEI+PEZPTlQgY29sb3I9IzAwMDA4MD4qursgwK/H0L/4wLogQkMgxKu1 5bvnIL+1sbm/rLz2ILvzx7Agx/m3wr73w7wgDQogICAgICAgICAgICDA1LTPtNkuPC9GT05UPjwv Qj48L0ZPTlQ+PC9QPg0KICAgICAgICAgICAgPFA+PC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFC TEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0063_01C11EC7.693216A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Mon Aug 6 7:37:52 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id D371137B405 for ; Mon, 6 Aug 2001 07:37:49 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=55cb9bab91644f6430a2a0ad8f02e27d) by softweyr.com with esmtp (Exim 3.16 #1) id 15Tlbs-0000nI-00; Mon, 06 Aug 2001 08:44:00 -0600 Message-ID: <3B6EAD30.8161F4E5@softweyr.com> Date: Mon, 06 Aug 2001 08:44:00 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ted Mittelstaedt Cc: j mckitrick , freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ted Mittelstaedt wrote: > > Also according to the Netcraft survey: > > "Primarily this is a result of two large US installations converting from > Solaris. " > > And also note that one of the sites, Interland, was partly owned by Microsoft > so of course they would go to NT. (they aren't anymore, but of course as you > know it takes a while to start large migration projects) > > Solaris already has good SMP, much better than Microsoft's. I don't see that > this was a factor. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Or just about anyone else's. Solaris probably has the best SMP scalability of anything out there in UNIX-land. They've been working on it for quite a while now. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Mon Aug 6 23:59:23 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 88C5837B401 for ; Mon, 6 Aug 2001 23:59:20 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA03241; Mon, 6 Aug 2001 23:56:28 -0700 (PDT) Message-ID: <3B6F9145.54945750@mindspring.com> Date: Mon, 06 Aug 2001 23:57:09 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: Ted Mittelstaedt , j mckitrick , freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> <3B6EAD30.8161F4E5@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wes Peters wrote: > > Solaris already has good SMP, much better than Microsoft's. I > > don't see that this was a factor. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Or just about anyone else's. Solaris probably has the best SMP > scalability of anything out there in UNIX-land. They've been > working on it for quite a while now. Solaris has the same 4 processor scaling limitation that they inherited from SVR4.01 ES/MP. This is primarily the result of their VM system, and their adoption of the SLAB allocator. The just don't build boards with more than 4 processors on them, so "it's not an issue". The 8-CPU Xeon boards that Intel has been coming up with lately are not going to run well without some serious architectural changes... not that they seem to be supporting Solaris on those things, anyway. That's why they do clustering to get a lot of CPUs on a problem (e.g. the "Sun GridEngine" that people have been looking at porting to FreeBSD). FreeBSD is setting itself up to be similarly limited; Linux already is hitting its head on the same issue. NT has done some smart things up front to skirt these issues, when the time comes. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 0:19:15 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id 4EAE137B401 for ; Tue, 7 Aug 2001 00:19:11 -0700 (PDT) (envelope-from tedm@toybox.placo.com) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id f7774t804961; Tue, 7 Aug 2001 00:04:55 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: , "Wes Peters" Cc: "j mckitrick" , Subject: RE: time to step up to the SMP plate? Date: Tue, 7 Aug 2001 00:04:55 -0700 Message-ID: <002301c11f0f$433b1300$1401a8c0@tedm.placo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3B6F9145.54945750@mindspring.com> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG But this is all Intel SMP isn't it? My understanding is that few to nobody running Solaris on SMP systems with more than 4 CPU's is using Intel boxes, instead they are using Sun hardware. The other $64 question of course is what ever happened to the 64 bit Intel CPU architecture? Supposedly the speed increase by going to 64 bit on a uniproccessor system would be so incredibly overwhelming that you would be junking all your 4 and 8 CPU SMP systems, acccording to the marketing from Intel I read... ;-) Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-----Original Message----- >From: Terry Lambert [mailto:tlambert2@mindspring.com] >Sent: Monday, August 06, 2001 11:57 PM >To: Wes Peters >Cc: Ted Mittelstaedt; j mckitrick; freebsd-advocacy@FreeBSD.ORG >Subject: Re: time to step up to the SMP plate? > > >Wes Peters wrote: >> > Solaris already has good SMP, much better than Microsoft's. I >> > don't see that this was a factor. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Or just about anyone else's. Solaris probably has the best SMP >> scalability of anything out there in UNIX-land. They've been >> working on it for quite a while now. > >Solaris has the same 4 processor scaling limitation that >they inherited from SVR4.01 ES/MP. This is primarily the >result of their VM system, and their adoption of the SLAB >allocator. The just don't build boards with more than 4 >processors on them, so "it's not an issue". The 8-CPU >Xeon boards that Intel has been coming up with lately are >not going to run well without some serious architectural >changes... not that they seem to be supporting Solaris on >those things, anyway. That's why they do clustering to >get a lot of CPUs on a problem (e.g. the "Sun GridEngine" >that people have been looking at porting to FreeBSD). > >FreeBSD is setting itself up to be similarly limited; Linux >already is hitting its head on the same issue. > >NT has done some smart things up front to skirt these issues, >when the time comes. > >-- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 4:11:42 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 738FF37B401 for ; Tue, 7 Aug 2001 04:11:40 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97] helo=dogma) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 15U4lq-0001wv-00; Tue, 7 Aug 2001 12:11:34 +0100 Received: (from jcm@localhost) by dogma (8.11.4/8.11.1) id f77BBXO73933; Tue, 7 Aug 2001 12:11:34 +0100 (BST) (envelope-from jcm) Date: Tue, 7 Aug 2001 12:11:33 +0100 From: j mckitrick To: Terry Lambert Cc: Wes Peters , Ted Mittelstaedt , freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? Message-ID: <20010807121133.A73889@dogma.freebsd-uk.eu.org> References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> <3B6EAD30.8161F4E5@softweyr.com> <3B6F9145.54945750@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3B6F9145.54945750@mindspring.com>; from tlambert2@mindspring.com on Mon, Aug 06, 2001 at 11:57:09PM -0700 Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG | FreeBSD is setting itself up to be similarly limited; Linux | already is hitting its head on the same issue. Is it possible the real limit here is just the practical limit of open source development? When almost everyone is a volunteer working in their spare time, not only is management and design difficult, development can slow to a crawl for a myriad reasons. I've seen more than one comment lately where this is becoming a concern. jm -- "Investigators have discovered the cause of the TWA 800 explosion was a frayed wire. The wire became frayed when it was struck by a missile." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 4:47: 1 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id E4A1A37B401 for ; Tue, 7 Aug 2001 04:46:56 -0700 (PDT) (envelope-from tedm@toybox.placo.com) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id f77BiJ805864; Tue, 7 Aug 2001 04:44:20 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "j mckitrick" , "Terry Lambert" Cc: "Wes Peters" , Subject: RE: time to step up to the SMP plate? Date: Tue, 7 Aug 2001 04:44:19 -0700 Message-ID: <002601c11f36$4b0b2080$1401a8c0@tedm.placo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20010807121133.A73889@dogma.freebsd-uk.eu.org> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG One of the things about Open Source development is that the laws of diminishing returns set in sooner than in commercial software. This gives rise to some interesting permutations in the software. For example, everyone criticizes sysinstall and would love a GUI installer - but nobody can possibly justify the effort of throwing out a program that you basically use ONCE then toss aside. By contrast, you take commercial software like Windows where they have totally overengineered the installers to the point that the installer makes so many decisions for you that you can end up with a system totally crunched because the installer decided to put THIS over THERE ontop of THAT. I think if you look at the parts of any Open Source program where development has slowed to a crawl, you will find some feature lacking that maybe 5% of the users want - and the other 95% don't give a rat's ass for. Of course that 5% is very vocal about their unhappiness! Even this discussion over SMP. Throughout the years there have been numberous flirtations with SMP on the desktop market. I can remember a dual 486/66 for example that I loaded NT 3.1 on, made by Vtech if you can belive it. (yes, the kid's toy manufacturer) The problem is that as Terry pointed out, SMP is not easy. It turns out that due to the leaps and bounds growth in desktop hardware ability, that in just about all of the installations out there, for the same money, often less, you can replace your existing uniprocessor hardware with the next generation uniprocessor hardware and get the power growth that you need as it would be to completely redesign the kernel from scratch to take advantage of SMP to the utmost. To give you an example, Compaq came out with rack mounted dual Pentium 200Mhz servers not too long ago - within a year the uniprocessor Pentium 400's had outperformed the dual 200's in most benchmarks because the applications that people were running on them were not multithreaded, and the bottleneck was the disk I/O which was greatly speeded up in the later machines. So, while adding SMP to FreeBSD was kind of a "gee whiz, we proved we can do it" kind of thing, you can see why most of the attention has been focused elsewhere. SMP is still useful on FreeBSD for some things and it espically helps those who happen to have a dual-slotted motherboard and are interested in just tossing a couple hundred dollars into something that will make the system go a little bit faster without doing a forklift upgrade. This isn't to say that we will never see SMP regularly used - indeed we are already seeing it. Most users don't, of course, recognize it. But the fact is that the CPU in a graphics card or a smart peripheral is a form of multiprocessing - it's not SMP but it is distributed processing. As far as the slow pace of development goes - well at the current time FreeBSD is useful for quite a lot of things. I daresay that it's useful for ALL of the things that MOST of the people using it want to do with it. The folks that are still complaining about the slow pace of development on it may have legitimate beefs - but they are doing things that are more esoteric than the average user. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-----Original Message----- >From: j mckitrick [mailto:jcm@freebsd-uk.eu.org] >Sent: Tuesday, August 07, 2001 4:12 AM >To: Terry Lambert >Cc: Wes Peters; Ted Mittelstaedt; freebsd-advocacy@FreeBSD.ORG >Subject: Re: time to step up to the SMP plate? > > >| FreeBSD is setting itself up to be similarly limited; Linux >| already is hitting its head on the same issue. > >Is it possible the real limit here is just the practical limit of open >source development? When almost everyone is a volunteer working in their >spare time, not only is management and design difficult, development can >slow to a crawl for a myriad reasons. > >I've seen more than one comment lately where this is becoming a concern. > > >jm >-- >"Investigators have discovered the cause of the TWA 800 explosion >was a frayed wire. The wire became frayed when it was struck >by a missile." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 7:21: 2 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from sherline.net (216-203-226-2.customer.algx.net [216.203.226.2]) by hub.freebsd.org (Postfix) with SMTP id 47C3137B413 for ; Tue, 7 Aug 2001 07:20:58 -0700 (PDT) (envelope-from jeremiah@sherline.com) Received: (qmail 37408 invoked from network); 7 Aug 2001 14:20:56 -0000 Received: from cx443070-b.vista1.sdca.home.com (HELO cx443070b) (24.0.36.170) by 216-203-226-2.customer.algx.net with SMTP; 7 Aug 2001 14:20:56 -0000 Message-ID: <005001c11f4c$2409eb90$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "Ted Mittelstaedt" , "j mckitrick" , "Terry Lambert" Cc: "Wes Peters" , References: <002601c11f36$4b0b2080$1401a8c0@tedm.placo.com> Subject: Re: time to step up to the SMP plate? Date: Tue, 7 Aug 2001 07:20:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Ted Mittelstaedt" To: "j mckitrick" ; "Terry Lambert" Cc: "Wes Peters" ; Sent: Tuesday, August 07, 2001 4:44 AM Subject: RE: time to step up to the SMP plate? > One of the things about Open Source development is that the laws of > diminishing returns set in sooner than in commercial software. > > This gives rise to some interesting permutations in the software. > For example, everyone criticizes sysinstall and would love a GUI > installer - but nobody can possibly justify the effort of throwing > out a program that you basically use ONCE then toss aside. To isolate a single point, how can people be critical of sysinstall ? Certainly from a text base 'GUI' standpoint, some things could be improved, but jeez, look at OpenBSD and to a point NetBSD. At least NetBSD has some nice little dialog boxes. OpenBSD's installer is a complete joke. A joke that isn't funny. I've always wished they'd realize what the BSD license is and just _take_ sysinstall and use it for their installer. The same with the FreeBSD boot loader (ever try multi-booting OpenBSD ?). > Even this discussion over SMP. Throughout the years there have been > numberous flirtations with SMP on the desktop market. I can remember > a dual 486/66 for example that I loaded NT 3.1 on, made by Vtech if you > can belive it. (yes, the kid's toy manufacturer) Hah ! I had a Vtech that had a single line LCD display, and you could type BASIC one line at a time, into an interpreter and make neat little programs. Sorry, I had to throw that in there :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 9:41:18 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from q.closedsrc.org (ip233.gte15.rb1.bel.nwlink.com [209.20.244.233]) by hub.freebsd.org (Postfix) with ESMTP id 6DEDB37B40D for ; Tue, 7 Aug 2001 09:41:16 -0700 (PDT) (envelope-from lplist@closedsrc.org) Received: by q.closedsrc.org (Postfix, from userid 1003) id C90F555407; Tue, 7 Aug 2001 09:38:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by q.closedsrc.org (Postfix) with ESMTP id BB32A51610; Tue, 7 Aug 2001 09:38:49 -0700 (PDT) Date: Tue, 7 Aug 2001 09:38:49 -0700 (PDT) From: Linh Pham To: Ted Mittelstaedt Cc: , Wes Peters , j mckitrick , Subject: RE: time to step up to the SMP plate? In-Reply-To: <002301c11f0f$433b1300$1401a8c0@tedm.placo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2001-08-07, Ted Mittelstaedt scribbled: # The other $64 question of course is what ever happened to the 64 bit # Intel CPU architecture? Supposedly the speed increase by going to 64 bit # on a uniproccessor system would be so incredibly overwhelming that you # would be junking all your 4 and 8 CPU SMP systems, acccording to the # marketing from Intel I read... ;-) Oh.. you mean the Intel iTanic... oops... I mean Itanium? It's still in development in a way :) The reference server configuration for the iTanic server allows for 4 processors... so I don't think that Intel will be leaving SMP systems behind any time soon :) -- Linh Pham [lplist@closedsrc.org] // 404b - Brain not found To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 10:27:16 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id B101837B403 for ; Tue, 7 Aug 2001 10:27:05 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.118.Dial1.SanJose1.Level3.net [209.244.105.118]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA27996; Tue, 7 Aug 2001 10:26:09 -0700 (PDT) Message-ID: <3B7024D9.55EAFBDD@mindspring.com> Date: Tue, 07 Aug 2001 10:26:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: j mckitrick Cc: Wes Peters , Ted Mittelstaedt , freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> <3B6EAD30.8161F4E5@softweyr.com> <3B6F9145.54945750@mindspring.com> <20010807121133.A73889@dogma.freebsd-uk.eu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG j mckitrick wrote: > > | FreeBSD is setting itself up to be similarly limited; Linux > | already is hitting its head on the same issue. > > Is it possible the real limit here is just the practical limit of open > source development? When almost everyone is a volunteer working in their > spare time, not only is management and design difficult, development can > slow to a crawl for a myriad reasons. > > I've seen more than one comment lately where this is becoming a concern. I remain convinced that the major limitations in Open Source developement models are emergent properties of the tools that are being used. It's true that there are a number of obstacles to sustained developement inherent in the model, but its also true that commercial interests and academic research can more than make up for any inhernet shortcomings, if the projects can be convinced to accept the fruits of that labor. When I first wrote loadable kernel modules and released them shortly before the Novell purchase of USL back in 1994, they were a small project that had been carried out in a (mostly) academic setting: my first prototypes were in 1993 on an SVR3 system in a University lab, since the GNU toolchain didn't support PIC compilation, until Jeffrey Hsu added support to it. Even then, it wasn't until several months after NetBSD adopted the code that FreeBSD grudgingly adopted the code as well. It's also ironic, I think, that the KLD stuff there today is the original design I wanted: a small linker in the kernel, capable of directly loading modules without outside intervention, but that design was shouted down as causing "too much kernel bloat". The funny thing about that is that it has resulted in exactly the opposite effect, as most drivers are now available as kernel modules, and aren't loaded unless the hardware is present, or the code is in the boot path. I could make similar claims about my SYSINIT() code, which Julian integrated over a number of strong objections, but is now taken for granted as something that can't be lived without, and has grown beyond the original scope of the work, in order to support tunables, both at boot time and run time, the list of which is aggregated out of the available code. So isolated small projects can result in big returns, though there have been isolated mishaps, like the failure to integrate Jack Vogel's work at Sun Microsystems into a functioning SMP for FreeBSD, until much later in the game: FreeBSD had a working SMP version, for some definitions of working, as of October 27th, 1995; the code provided much of the basis for the work which was eventually integrated, although it passed from Jack's hands to mine to Peter and Steve, and the rest of the people who ended up integrating it into the then much-changed FreeBSD tree. Things like Luigi's SACK, FACK, and TSACK implementations have pretty much languished; TSACK isn't really useful any more, now that Microsoft clients support SACK directly. Similarly, the reimplementations at Pittsburgh have failed to be integrated, even though they were developed on FreeBSD, and QLinux has LRP and Fair Share shecduling, even though the Rice University work was all done on FreeBSD boxes, once it was broken out of the Scala Server Project. There are literally tens of dozens of similar failures to execute in the past of most large Open Source projects, and, it seems to me, more in the future. In FreeBSD's case, it's mostly an issue of the tools being unable to handle multiple lines of developement, which has resulted in the "One True HEAD Branch" phenomenon, where work not occurring on -current is often discarded, due to the emotional investment people have in -current. Linux avoided this serialization problem, only to fall victim to its own similar issue of serializing through Linus (or Alan Cox), for lack of a source code control system. Linus has really never articulated well his gut reaction to source code control, instead engaging in much hand waving, but it's clear that he sees the danger of being locked into particular emergent properties by the tools, even if he doesn't give very rational justification for his gut feelings. We had a nice example of the "gated community" effect when Matt Dillon became able to dedicate a significant amount of his time to working on FreeBSD, after Best Internet, the company he helped found, was acquired by by Verio. The gatekeepers were simply unable to keep up with his rate of contribution of code, made over 8 and 12 hour days, and they squelched him, taking away his commit bits until he agreed to slow down to a much slower pace, where they could keep up with reviewing code. I think that FreeBSD has suffered from incidents like this in the past (e.g. John Dyson leaving the community was a major loss, IMO), and it comes down to the "One True HEAD Branch" phenomenon, once again, where the only way for ideas to compete openly is for them to be implemented in different distributions... since all of the BSD projects have the same form-factor: core team of gate keepers, committers, and the threat of removing commit bits temporarily, until someone complies. The bottom line is that real developement on anything but the HEAD branch rarely occurs (except for the commercially funded developement, which can't risk -current in a shipping product), and so their work occurs on -stable, which ends up being "the dead branch", where MFC is the rule, and MTC rarely happens (MFC = Merge From Current; MTC = Merge To Current). For example, I have several changes that I've done to FreeBSD 4.3; one up'ed the open network connection limitation from 32k, and has been tested up to 1.6M simultaneous connections. With slightly more time, I could easily push this to 2M or further. I also have changes to the TCP/IP stack, as well as several other changes to network drivers and such, which I believe could yield a 40% or better performance improvement on the top end, and minimally a 30% improvement in overall throughput capacity under extreme load (as opposed to falling off to near zero). One of the changes effectively eliminates NETISR: Van Jacobson's "holy grail". Although the company I work for seems willing to let the code back into the main line FreeBSD tree after two product release cycles, if only to offload the maintenance burden, and so our implementation "wins", it will probably not make it back into FreeBSD, since the changes are against 4.3-stable, not -current, and -current is moving at what commercially can only be considered a reckless speed, in directions not entirely justified by research or the Computer Science literature (certainly, no one is citing papers or research which justify the design decisions being made). So getting back to the inital point, I think it is a tools issue, probably more than anything else, which has the emergent property of selecting one "blessed" branch, and sending all the rest off to Coventry. I've only been surpriased in this opinion once so far, and I have been involved behind the scenes or out front in the genesis of no less than six Open Source projects. The surprise came from the OpenLDAP project, which took the University of Michigan code, and applied "The FreeBSD Patches" -- 120k of diffs from me, collected in "patchkit style" from a number of sources, particularly Critical Angle's site, which archived, but didn't organize or review the patches -- and then imported the UMich code, the patches, and then went on from there. My surprise arose from what I contend will be the next battlefield in Open Source vs. Commercial developement: complexity. I felt that it would not be possible, in the context of an Open Source project, to implement the LDAPv3 protocol. Kurt Zeilenga, happily, proved me wrong, mostly because of the commercial support of the Net Boolean... and his position, relative to the project, as an "alive and kicking" project founder. I believe had it not been for that, the OpenLDAP project would have failed to achive LDAPv3 interoperability. It seems like several commercial companies have latched onto "the complexity defense" to throw up barriers to entry, in an attempt to keep Open Source out of their mainstream commercial markets. I watch the IETF very closely, and participate when I feel it's needed, and I have to say I've recently seen some of the most arcane and unnecessarily complex RFCs shoved through the IETF standardization process by large companies working in concert, in what can only be described as protectionist tactics. Hopefully, Open Source will be able to overcome its inherit handicaps; it may be that FreeBSD switches to using Perforce, or some other tool that gets rid of the "One True Head Branch" phenomenon, despite the commercial use pain that such a switch would entail (P4 is free for Open Source, but not for commercial companies tracking an Open Source project, whose repository is only available in P4). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 10:46:52 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 939CE37B40D for ; Tue, 7 Aug 2001 10:46:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.118.Dial1.SanJose1.Level3.net [209.244.105.118]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA21142; Tue, 7 Aug 2001 10:46:15 -0700 (PDT) Message-ID: <3B702990.CC88CC62@mindspring.com> Date: Tue, 07 Aug 2001 10:46:56 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremiah Gowdy Cc: Ted Mittelstaedt , j mckitrick , Wes Peters , freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? References: <002601c11f36$4b0b2080$1401a8c0@tedm.placo.com> <005001c11f4c$2409eb90$aa240018@cx443070b> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeremiah Gowdy wrote: > > This gives rise to some interesting permutations in the software. > > For example, everyone criticizes sysinstall and would love a GUI > > installer - but nobody can possibly justify the effort of throwing > > out a program that you basically use ONCE then toss aside. > > To isolate a single point, how can people be critical of sysinstall ? > Certainly from a text base 'GUI' standpoint, some things could be improved, > but jeez, look at OpenBSD and to a point NetBSD. At least NetBSD has some > nice little dialog boxes. OpenBSD's installer is a complete joke. A joke > that isn't funny. I've always wished they'd realize what the BSD license is > and just _take_ sysinstall and use it for their installer. The same with > the FreeBSD boot loader (ever try multi-booting OpenBSD ?). The point is, except for OEM loads, which Linux is pursuing, and FreeBSD has failed to pursue successfully, the first user experience is the installer. It is therefore the installer where one captures (or loses) mindshare: if someone can not load your code, without fear, then they will never try it. People (myself included, and, I think, Jordan, thruth be told) are critical of sysinstall because it is only comparatively better: pick a different product to compare to, like Windows ME Upgrade, and what "better" you could argue goes right out the window. The issue with the installer is one of editorial control, and permissable use of the trademark, more than anything else. I think the trademark issue was clarified sufficiently the last this discussion arose (finally!), so now it's just a matter of someone seeing some money in improving things, or someone taking the albatross about their neck, and doing the work for free. If no one beats me to it, I will eventually get around to dealing with the package registration of base system components, once the NetBSD rc system has been MFC'ed (or when -current becomes -stable). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 11:47:26 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from ancmail1.state.ak.us (dced.state.ak.us [146.63.92.75]) by hub.freebsd.org (Postfix) with ESMTP id 9528F37B401 for ; Tue, 7 Aug 2001 11:47:19 -0700 (PDT) (envelope-from brian_raynes@dnr.state.ak.us) Received: from dnr.state.ak.us ([146.63.110.115]) by ancmail1.state.ak.us (Netscape Messaging Server 4.15) with ESMTP id GHPO6U00.S55; Tue, 7 Aug 2001 10:47:18 -0800 Message-ID: <3B70383E.E34C7D7@dnr.state.ak.us> Date: Tue, 07 Aug 2001 10:49:34 -0800 From: Brian Raynes X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeremiah Gowdy , freebsd-advocacy@freebsd.org Subject: Re: time to step up to the SMP plate? References: <002601c11f36$4b0b2080$1401a8c0@tedm.placo.com> <005001c11f4c$2409eb90$aa240018@cx443070b> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeremiah Gowdy wrote: > > ----- Original Message ----- > From: "Ted Mittelstaedt" > To: "j mckitrick" ; "Terry Lambert" > > Cc: "Wes Peters" ; > Sent: Tuesday, August 07, 2001 4:44 AM > Subject: RE: time to step up to the SMP plate? > > > This gives rise to some interesting permutations in the software. > > For example, everyone criticizes sysinstall and would love a GUI > > installer - but nobody can possibly justify the effort of throwing > > out a program that you basically use ONCE then toss aside. > > To isolate a single point, how can people be critical of sysinstall ? > Certainly from a text base 'GUI' standpoint, some things could be improved, > but jeez, look at OpenBSD and to a point NetBSD. At least NetBSD has some > nice little dialog boxes. OpenBSD's installer is a complete joke. A joke > that isn't funny. I've always wished they'd realize what the BSD license is > and just _take_ sysinstall and use it for their installer. The same with > the FreeBSD boot loader (ever try multi-booting OpenBSD ?). I agree about sysinstall. From a newbie, strictly user perspective, it's plenty easy to use. Adding fancy graphics will not make understanding network setup or package selection any easier than it currently is. Even Windows requires you to know these things for TCP/IP networking - there is no avoiding _some_ know-how for networking. You really don't have to come up with true GUI to make a graphical disk formatting/ disklabel setup. That's the only thing I've noticed that might be made easier for a newbie install with a more graphical, intuitive approach. But as you said, that's a tweak more than a complete overhaul (at least from an interface point of view, I've read Jordan's comments about what hell the code is, and I will have to take his word for it - but that's really a separate issue). Regarding OpenBSD, it was the first BSD installer that I actually completed a successful install with. It is a bit sparse, but OpenBSD aims for a very minimum initial install, with most of the other chores done afterwards using guidance from the FAQ and man pages. That's not wholly newbie friendly and may be a bit time consuming even if you know how, but when I got done, it did exactly what I wanted it to do, and nothing more or less. I really appreciated that, actually. I know it's because of my lack of experience, but FreeBSD installs always seem to do a little more for me than I expected, causing error messages that I don't yet know how to fix or am not quite ready to deal with yet. It's ok, though, since the system still generally works and I will eventually get things like NFS setup the rest of the way. But I thought that statement about the OpenBSD installer needed an alternative point of view. In the end, I actually did better working through OpenBSD's more manual approach, because I knew as I went, exactly what everything was doing and why. I wouldn't be bothered at all if both FreeBSD and OpenBSD made both of their methods of install an option. Your comment about their bootloader might on target (if I ever get around to learning programming in C, I'll jump right on it:) ). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Tue Aug 7 18:54:17 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from wilma.widomaker.com (wilma.widomaker.com [204.17.220.5]) by hub.freebsd.org (Postfix) with ESMTP id C4F0337B401 for ; Tue, 7 Aug 2001 18:54:08 -0700 (PDT) (envelope-from shannon@daydream.shannon.net) Received: from [209.96.179.201] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 15UIXt-000KCr-00 for freebsd-advocacy@freebsd.org; Tue, 07 Aug 2001 21:54:06 -0400 Received: from daydream (daydream.shannon.net [192.168.1.10]) by escape.shannon.net (8.11.0/8.8.8) with ESMTP id f781prw08574 for ; Tue, 7 Aug 2001 21:51:53 -0400 (EDT) Received: from shannon by daydream with local (Exim 3.12 #1 (Debian)) id 15UIVl-0002da-00 for ; Tue, 07 Aug 2001 21:51:53 -0400 Date: Tue, 7 Aug 2001 21:51:53 -0400 From: Charles Shannon Hendrix To: freebsd-advocacy@FreeBSD.ORG Subject: Re: time to step up to the SMP plate? Message-ID: <20010807215153.B9801@widomaker.com> Mail-Followup-To: freebsd-advocacy@FreeBSD.ORG References: <003f01c11cd7$563d7860$1401a8c0@tedm.placo.com> <3B6EAD30.8161F4E5@softweyr.com> <3B6F9145.54945750@mindspring.com> <20010807121133.A73889@dogma.freebsd-uk.eu.org> <3B7024D9.55EAFBDD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B7024D9.55EAFBDD@mindspring.com> User-Agent: Mutt/1.3.18i Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 07, 2001 at 10:26:49AM -0700, Terry Lambert wrote: > I remain convinced that the major limitations in Open Source > developement models are emergent properties of the tools that > are being used. [snip] > In FreeBSD's case, it's mostly an issue of the tools being unable > to handle multiple lines of developement, which has resulted in > the "One True HEAD Branch" phenomenon, where work not occurring > on -current is often discarded, due to the emotional investment > people have in -current. I have always wanted a tool that scaled well from just me, to a team, and did so without putting some draconian in charge of releases. If a team is well disciplined and has good leadership, the tools created generally follow and the project has little need for the kingdom-builders that infest so much corporate work I've been in. It's quite true that there isn't a lot of software to support some things that are beginning to become more of a problem: * very large projects * very complex projects * ...which last a long time * ...where team members come and go, maybe even the leaders * ...which need to maintain patches against multiple releases * ...which need discipline * ...needing to produce very, very reliable work I don't really see this as an open source vs commerical problem since there aren't many tools _anywhere_ that sucessfully handle these problems. Most good projects succeed because they have really great leaders and a small number of heroic developers, often in spite of their tools and management. Maybe if open source projects started working harder on their management, the tools would follow, but an effort to address tool issues should be made anyway. Open source isn't necessarily new, but having open projects on the kind of scale we have today is <10 years old, so it might just be we are still learning. As an industry, we seem to be very bad about not learning from our mistakes. Are there any projects out there working on tools to fix problems with scale, multiple-branches, discipline, and the now-common situation where project members come and go? > Although the company I work for seems willing to let the code back > into the main line FreeBSD tree after two product release cycles, if > only to offload the maintenance burden, and so our implementation > "wins", it will probably not make it back into FreeBSD, since the > changes are against 4.3-stable, not -current, and -current is moving > at what commercially can only be considered a reckless speed, in > directions not entirely justified by research or the Computer Science > literature (certainly, no one is citing papers or research which > justify the design decisions being made). This is a problem with a large number of projects out there. I would say that Gnome has this problem, but much, much worse. Maybe with large companies getting interested, they will help change that. Evidently Sun has recently issued a paper or something with a list of changes needed in Gnome. It's very easy to let a project get into an extended (possibly endlesss) phase of tacking on features or putting out fires. Not much difference between the two in terms of what it does to a project. Really "designing" software isn't easy, not matter how easy it might seem on simpler projects, where pure zeal might get you through it. I think a lot of the open source world still needs to learn this lesson. > So getting back to the inital point, I think it is a tools issue, > probably more than anything else, which has the emergent property > of selecting one "blessed" branch, and sending all the rest off to > Coventry. My biggest problem with the tools when working as part of a team is the difficulty in managing branches of the code base. I don't just mean a "one head" problem, I mean any kind of branching. Some concepts of branching are needlessly difficult to get your head around, and mistakes are very, very easy to make even if you have been doing it for years. CVS, for example, has done little to make the old RCS branching methods any easier to work with. Most commercial tools seem to solve development problems by beating them to death. When I was forced to use PVCS, I kept my own tree managed with some shell scripts. Like a lot of tools, it was heavy on features for the designated overlords, but few for the programmer (that worked). I have heard good things about some other tools, but often they are not universal or are too expensive for me to even afford a single user copy. That's definitely going to be a barrier to open source projects using them, and in the end I really think open source needs an open tool to use. > It seems like several commercial companies have latched onto "the > complexity defense" to throw up barriers to entry, in an attempt to > keep Open Source out of their mainstream commercial markets. I > watch the IETF very closely, and participate when I feel it's > needed, and I have to say I've recently seen some of the most > arcane and unnecessarily complex RFCs shoved through the IETF > standardization process by large companies working in concert, in > what can only be described as protectionist tactics. No doubt about it. Also, often those companies can manage the resulting projects through abuse of their labor force, not better methodology. Just about everywhere I have worked there is this pool of code-monkeys who will foolishly do 70 hour work weeks without overtime. It was fear, not tools, that enabled them to complete complex projects. As long as they can get away with that, they'll continue to stupidly reinvent the wheel and produce complexity instead of sophistication. Obviously you cannot do that to open source volunteers, nor should you want to. I think we'll find better ways, and the really good companies will too, since eventually the monkeys get ticked off and quit. Eeeeeee eeeeeee eeeeeee... :) > Hopefully, Open Source will be able to overcome its inherit > handicaps; it may be that FreeBSD switches to using Perforce, or > some other tool that gets rid of the "One True Head Branch" > phenomenon, despite the commercial use pain that such a switch > would entail (P4 is free for Open Source, but not for commercial > companies tracking an Open Source project, whose repository is > only available in P4). I would worry about committing to a tool that may or may not remain free in the future. It would be better to come up with an open solution. -- "I wish life was not so short. Languages take such a time, and so do all the things one wants to know about." - J. R. R. Tolkien ______________________________________________________________________ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Wed Aug 8 7:54:32 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 3765B37B40A for ; Wed, 8 Aug 2001 07:54:29 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA17981; Wed, 8 Aug 2001 07:53:57 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010807215153.B9801@widomaker.com> Date: Wed, 08 Aug 2001 07:53:58 -0700 (PDT) From: John Baldwin To: Charles Shannon Hendrix Subject: Re: time to step up to the SMP plate? Cc: freebsd-advocacy@FreeBSD.org Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Aug-01 Charles Shannon Hendrix wrote: >> Hopefully, Open Source will be able to overcome its inherit >> handicaps; it may be that FreeBSD switches to using Perforce, or >> some other tool that gets rid of the "One True Head Branch" >> phenomenon, despite the commercial use pain that such a switch >> would entail (P4 is free for Open Source, but not for commercial >> companies tracking an Open Source project, whose repository is >> only available in P4). > > I would worry about committing to a tool that may or may not remain free > in the future. It would be better to come up with an open solution. Have you _used_ p4? :) It makes working on WIP's that aren't in HEAD yet _much_ easier. We've already got a p4 branch for the KSE work, and another one for SMPng work that isn't committed yet. If you want to rewrite p4, go for it, but it would take you a long time to do it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message From owner-freebsd-advocacy Wed Aug 8 11:46:30 2001 Delivered-To: freebsd-advocacy@freebsd.org Received: from softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id A0B0B37B405; Wed, 8 Aug 2001 11:46:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=567ca764bb7e3493bbc4cd4a80e2e415) by softweyr.com with esmtp (Exim 3.16 #1) id 15UYTS-000065-00; Wed, 08 Aug 2001 12:54:34 -0600 Message-ID: <3B718AEA.F17009EA@softweyr.com> Date: Wed, 08 Aug 2001 12:54:34 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Charles Shannon Hendrix , freebsd-advocacy@FreeBSD.org Subject: Re: time to step up to the SMP plate? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 08-Aug-01 Charles Shannon Hendrix wrote: > > > > I would worry about committing to a tool that may or may not remain free > > in the future. It would be better to come up with an open solution. > > Have you _used_ p4? :) It makes working on WIP's that aren't in HEAD yet > _much_ easier. We've already got a p4 branch for the KSE work, and another one > for SMPng work that isn't committed yet. If you want to rewrite p4, go for it, > but it would take you a long time to do it. Plus, perforce cannot magically become "un-free". They can refuse to grant licenses to future upgrades if they change their mind, but they can't unilaterally go back and un-grant an existing license to existing code. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message