From owner-freebsd-chat Sun Oct 22 4:21:10 2000 Delivered-To: freebsd-chat@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 693E037B4C5 for ; Sun, 22 Oct 2000 04:21:06 -0700 (PDT) Received: (qmail 93018 invoked by uid 1114); 22 Oct 2000 11:21:00 -0000 Date: 22 Oct 2000 04:21:00 -0700 Date: Sun, 22 Oct 2000 04:21:00 -0700 (PDT) From: Ceren Ercen To: Warner Losh Cc: chat@freebsd.org Subject: Re: boundage bsd daemon image In-Reply-To: <200010220425.WAA44388@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'll see if I can find it: that was my shirt. Note: the t-shirt was only printed in female sizes.... I'll see if I can find the original art, or I'll ask the artist to put it up on the web. and the phrase was "The only way to lock up this OS". ;) Quite a different meaning. Ceren On Sat, 21 Oct 2000, Warner Losh wrote: > Does anybody have a pointer to the "Only way to secure the BSD system" > shirt that showed up from time to time. I think it was a DEFCON image, > but not the separating the men from boys defcom shirt mike smith was wearking. > > Please CC me as I'm not on chat. Thanks much > > Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 9:27:37 2000 Delivered-To: freebsd-chat@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 7653337B4F9 for ; Sun, 22 Oct 2000 09:27:35 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id MAA21442; Sun, 22 Oct 2000 12:27:11 -0400 (EDT) Date: Sun, 22 Oct 2000 12:27:06 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: Will Andrews Cc: chat@FreeBSD.ORG, Frank Andrews Subject: Re: More BSDCon pics In-Reply-To: <20001020145716.B14799@csociety.ecn.purdue.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 20 Oct 2000, Will Andrews wrote: the person standing with me and wes is Peter Losher. > Hi all, > > Just letting you know my BSDCon pics site has been updated (although this > was about 12 hours ago). > > http://people.FreeBSD.org/~will/bsdcon/ > > 28 new images, and a much smaller number of blurry ones. By the way, Kris > Kennaway is not allowed to view these images. Do not let him see it, or > he is entitled to another of my famous middle fingers. > > ;-) > > -- > Will Andrews > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message > __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net VA Linux Systems trish@valinux.com O|S|D|N trish@osdn.com --- "how long till my soul gets it right can any human being ever reach that kind of light i call on the resting soul of galileo king of night vision, king of insight" -Indigo Girls, Galileo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 11:36:37 2000 Delivered-To: freebsd-chat@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 78E0137B479 for ; Sun, 22 Oct 2000 11:36:34 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id e9MIaXn77427; Sun, 22 Oct 2000 12:36:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA47687; Sun, 22 Oct 2000 12:36:32 -0600 (MDT) Message-Id: <200010221836.MAA47687@harmony.village.org> To: Ceren Ercen Subject: Re: boundage bsd daemon image Cc: chat@freebsd.org In-reply-to: Your message of "Sun, 22 Oct 2000 04:21:00 PDT." References: Date: Sun, 22 Oct 2000 12:36:32 -0600 From: Warner Losh Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Ceren Ercen writes: : I'll see if I can find it: that was my shirt. Thank you. I appreciate it. : I'll see if I can find the original art, or I'll ask the artist to put it : up on the web. OK. I'd be willing to pay for this as well. I know how hard it can be for artists to make a living... : and the phrase was "The only way to lock up this OS". ;) Quite a different : meaning. Ah, yes. That's true. But no less funny. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 12:38:40 2000 Delivered-To: freebsd-chat@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id 5888737B4C5 for ; Sun, 22 Oct 2000 12:38:38 -0700 (PDT) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA18168; Sun, 22 Oct 2000 13:38:10 -0600 (MDT) Message-Id: <4.3.2.7.2.20001022100009.00d40350@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Oct 2000 10:01:32 -0600 To: Ceren Ercen , Warner Losh From: Brett Glass Subject: Re: boundage bsd daemon image Cc: chat@FreeBSD.ORG In-Reply-To: References: <200010220425.WAA44388@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:21 AM 10/22/2000, Ceren Ercen wrote: >Note: the t-shirt was only printed in female sizes.... Which means, I take it, that a male has to cross-dress to wear it? ;-) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 15:29:18 2000 Delivered-To: freebsd-chat@freebsd.org Received: from svl.uzhgorod.ua (svl.uzhgorod.ua [194.42.192.87]) by hub.freebsd.org (Postfix) with ESMTP id 7A0AF37B479 for ; Sun, 22 Oct 2000 15:28:34 -0700 (PDT) Received: from localhost (user1.svl.uzhgorod.ua [194.42.193.181]) by svl.uzhgorod.ua (8.9.3/8.9.3) with SMTP id BAA74015 for ; Mon, 23 Oct 2000 01:28:01 +0300 (EEST) Message-ID: <001f01c03c6d$e89a44e0$0100007f@localhost> From: "=?koi8-r?B?69XazsXDz9cg7snLz8zByg==?=" To: Subject: Re: freebsd-chat-digest V1 #940 Date: Mon, 23 Oct 2000 01:20:25 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----Исходное сообщение----- От: freebsd-chat-digest Группы: lucky.freebsd.chat.digest Дата: 22 жовтня 2000 р. 8:26 Тема: freebsd-chat-digest V1 #940 > >freebsd-chat-digest Saturday, October 21 2000 Volume 01 : Number 940 > > > >In this issue: >oh, what gives with this??? >Re: oh, what gives with this??? >boundage bsd daemon image > >---------------------------------------------------------------------- > >Date: Fri, 20 Oct 2000 19:55:43 -0700 (MST) >From: John Reynolds >Subject: oh, what gives with this??? > >This seems a little hard to swallow ... I click on a "video" link after looking >at some stock quotes off Yahoo, thinking "cool, Real Video" (or something else >which has a Unix codec). Then, I'm greeted with this smug dialog box: > > Sorry! Yahoo! FinanceVision is supported only under Windows operating systems. > >FreeBSD runs the bloody place and they can't accomodate it for the end user? > >Gimme a break ... > > >FUCK YOU NIGER!!! >- -- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-= >John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation >jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running >jjreynold@home.com FreeBSD 4.1-STABLE. FreeBSD: The Power to Serve. >http://members.home.com/jjreynold/ Come join us!!! @ http://www.FreeBSD.org/ >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-= > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-chat" in the body of the message > >------------------------------ > >Date: Sat, 21 Oct 2000 11:30:55 -0400 (EDT) >From: rage >Subject: Re: oh, what gives with this??? > >why do yu think we affectionately call it 'Winblows' ? :P > > >On Fri, 20 Oct 2000, John Reynolds wrote: > >> >> This seems a little hard to swallow ... I click on a "video" link after looking >> at some stock quotes off Yahoo, thinking "cool, Real Video" (or something else >> which has a Unix codec). Then, I'm greeted with this smug dialog box: >> >> Sorry! Yahoo! FinanceVision is supported only under Windows operating systems. >> >> FreeBSD runs the bloody place and they can't accomodate it for the end user? >> >> Gimme a break ... >> >> >> >> -- >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-= >> John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation >> jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running >> jjreynold@home.com FreeBSD 4.1-STABLE. FreeBSD: The Power to Serve. >> http://members.home.com/jjreynold/ Come join us!!! @ http://www.FreeBSD.org/ >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-= >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-chat" in the body of the message >> > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-chat" in the body of the message > >------------------------------ > >Date: Sat, 21 Oct 2000 22:25:51 -0600 (MDT) >From: Warner Losh >Subject: boundage bsd daemon image > >Does anybody have a pointer to the "Only way to secure the BSD system" >shirt that showed up from time to time. I think it was a DEFCON image, >but not the separating the men from boys defcom shirt mike smith was wearking. > >Please CC me as I'm not on chat. Thanks much > >Warner > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-chat" in the body of the message > >------------------------------ > >End of freebsd-chat-digest V1 #940 >********************************** > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 17:15:48 2000 Delivered-To: freebsd-chat@freebsd.org Received: from athserv.otenet.gr (athserv.otenet.gr [195.170.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 690E337B479 for ; Sun, 22 Oct 2000 17:15:35 -0700 (PDT) Received: from hades.hell.gr (patr530-b019.otenet.gr [195.167.121.147]) by athserv.otenet.gr (8.10.1/8.10.1) with ESMTP id e9N0E8J18304; Mon, 23 Oct 2000 03:14:08 +0300 (EET DST) Received: (from charon@localhost) by hades.hell.gr (8.11.1/8.11.1) id e9N027a02132; Mon, 23 Oct 2000 03:02:07 +0300 (EEST) Date: Mon, 23 Oct 2000 03:02:06 +0300 From: Giorgos Keramidas To: Kuznecov Nikolaj Cc: chat@FreeBSD.ORG Subject: Re: freebsd-chat-digest V1 #940 Message-ID: <20001023030206.A2017@hades.hell.gr> References: <001f01c03c6d$e89a44e0$0100007f@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <001f01c03c6d$e89a44e0$0100007f@localhost>; from koly@alfa.svl.uzhgorod.ua on Mon, Oct 23, 2000 at 01:20:25AM +0400 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Nikolaj, Quoting the entire text of a message, without making clear where the original text is and where your writing, is not a good practise on this list, and one that is generally disliked by a lot of people. Even if I tried to put this aside, though, and try to read your message to find out what *you* wrote, when I, after a long effort to distinguish the quoted text from your own writings, discover that your only addition to the original text is... On 23 Oct 2000 01:20:25 +0400, Kuznecov Nikolaj wrote: >On 20 Oct 2000 19:55:43 -0700 (MST), John Reynolds wrote: >> ... >> >> Gimme a break ... >> >> > > FUCK YOU NIGER!!! ...when I look upon this offensive post, in all it's useless glory, I am quite sad that you had to express yourself in this way. I am sorry that this list has bothered you with it's postings so much that you had to become so impolite and rude. But I can only courteously ask that you remove yourself from this list, if you feel that it offends you so much that you have to write in such tone and manner. Then again, perhaps all this is just a mistake that results from the strange way your reply was formatted, and you did not really write the posting that I tried to recover from within your message's strange formatting. If that is the case, I owe you an apology and I can only ask that you format your messages in a more eligible and clearly set manner from now on. Yours faithfully, Giorgos Keramidas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 17:27: 1 2000 Delivered-To: freebsd-chat@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 1B3FE37B479 for ; Sun, 22 Oct 2000 17:27:00 -0700 (PDT) Received: by puck.firepipe.net (Postfix, from userid 1000) id 99E7418E4; Sun, 22 Oct 2000 19:26:50 -0500 (EST) Date: Sun, 22 Oct 2000 19:26:50 -0500 From: Will Andrews To: chat@FreeBSD.org Cc: Frank L Andrews Subject: Updated photos Message-ID: <20001022192650.A1604@puck.firepipe.net> Reply-To: Will Andrews Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, Now that I've returned home from BSDCon, I've posted the last pictures as a result of this.. shall we say.. excellent trip. :-) See http://people.FreeBSD.org/~will/bsdcon/ .. and don't flame me if some of them are blurry.. this means you Kris Kennaway. *duck* ;) Take care, -- Will Andrews - Physics Computer Network wench To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sun Oct 22 17:36:38 2000 Delivered-To: freebsd-chat@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id B415D37B4C5; Sun, 22 Oct 2000 17:36:35 -0700 (PDT) From: "Jonathan M. Bresler" To: ceren@magnesium.net Cc: imp@village.org, chat@freebsd.org In-reply-to: (message from Ceren Ercen on 22 Oct 2000 04:21:00 -0700) Subject: Re: boundage bsd daemon image Message-Id: <20001023003635.B415D37B4C5@hub.freebsd.org> Date: Sun, 22 Oct 2000 17:36:35 -0700 (PDT) Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ceren, I would also be interested in a shirt or two ;) jmb > > and the phrase was "The only way to lock up this OS". ;) Quite a different > meaning. > > Ceren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Oct 23 4:21:47 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id D1B7C37B4C5; Mon, 23 Oct 2000 04:21:40 -0700 (PDT) Received: from bissau-41.budapest.interware.hu ([195.70.53.169] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13nffd-0003pE-00; Mon, 23 Oct 2000 13:21:37 +0200 Message-ID: <39F41F39.CC9CB97@elischer.org> Date: Mon, 23 Oct 2000 04:21:29 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: archie@freebsd.org, chat@freebsd.org Subject: [Fwd: The truth is told !!!!] Content-Type: multipart/mixed; boundary="------------82BB9BC9E1CA4AC80240C86E" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------82BB9BC9E1CA4AC80240C86E Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v --------------82BB9BC9E1CA4AC80240C86E Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA33976 for ; Mon, 23 Oct 2000 00:10:31 -0700 (PDT) Received: from grunge.iinet.net.au (grunge.iinet.net.au [203.59.24.9]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id PAA21432; Mon, 23 Oct 2000 15:09:59 +0800 Received: (from uucp@localhost) by grunge.iinet.net.au (8.8.5/8.6.12) with UUCP id PAA24590; Mon, 23 Oct 2000 15:01:31 +0800 Received: from bonnie.triumph.com.au (bonnie.triumph.com.au [203.56.226.6]) by triumph.triumph.com.au (8.8.8/SCO5) with ESMTP id PAA16260; Mon, 23 Oct 2000 15:00:53 +0800 (WST) Message-Id: <4.3.2.7.2.20001023145723.00ac5450@triumph> X-Sender: apc@triumph X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Oct 2000 15:00:17 +0800 To: (Recipient list suppressed) From: Clive Richmond Subject: The truth is told !!!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mozilla-Status2: 00000000 Some new information has come to light over the Kursk disaster. For those with short attention spans, the Kursk was the submarine that blew up and sank in the Artic Ocean killing all 118 on board. The Russians tried to blame the incident on a collision with an unidentified object. However, sonar tapes which recorded the blasts (a small one at first, then a much larger one two minutes later) cast doubt on these claims. A whistle blower within the Russian military has leaked that the crew of the Kursk was testing a new type of torpedo when the accident occurred. It seemed very likely that the test didn't go quite as planned. While rescue efforts to save the survivors of the Kursk failed, salvage crews were able to recover a 'Black Box' from the submarine which contained detailed accounts of the events leading up to the explosion. As luck would have it, we got a copy of those tapes. It turns out that the submarine crew was trying to load Microsoft Windows on their fire control computer. Their intent was to replace the Unix operating system with the flashier Windows OS. Apparently, the Russians didn't know about the legendary stability problems exhibited by Windows. The log tapes make this painfully obvious: Captain: Is new fire control Windows OS installed yet, Comrade? Seaman: Almost Sir. Just need to finish filling out registration card. Captain: Excellent. Soon is being able to point and click our enemies into oblivion. [evil laughter in background] Seaman: Comrade Captain! Is booting! Look, it says "Preparing to run Windows for first time". [long pause] Seaman: Arrgh! Sir, is wanting me to reboot again. That makes 27th time. Captain: Hmmm. Is not encouraging. Go ahead and reboot again. Seaman: Aye, aye Sir. [another long pause] Seaman: Captain, is up again. Is saying it found new hardware... A CD-ROM drive and that is needing drivers. Captain: Where are drivers? Seaman: On CD-ROM. Captain: You are joking, right? Seaman: No Sir. Captain: Reboot damn thing again. I am starting not to liking this Windows. [another long pause] Seaman: Sir! Is back! Is saying it found the Gorby2000 Torpedo and is looking for device drivers. Do we have driver disk? Captain: I do not think so. Seaman: I will tell it to use default drivers. [another long pause] Seaman: Sir! Is wanting to reboot again. Captain: How many times are we going to reboot today? Is taking forever. Our hull is rusting out before this works. [another long pause] Seaman: Sir! Is up and this time is not asking for anything! Captain: Really? No device drivers? No registration cards? No user profiles? Seaman: No Sir. I think is ready. Captain: Good work comrade. Now is clicking on the fire control icon and letting us see how this works. Seaman: Is clicking now, Sir. [another long pause] Captain: Why does fire control screen have dancing paper clip on it? Seaman: I have no idea, Sir. Captain: Hmmm, is trying clicking on menu. Seaman: Aye Sir. Is saying: Open E-mail, Spam a friend, Mail a Virus, Fire a Torpedo. Captain: Is spamming friend later. Is firing torpedo now. Seaman: Aye Sir. [another long pause] Seaman: Is asking us to load torpedo and to click when ready. Captain: Torpedo room, load torpedo in tube number 1! [intercom:] This is Torpedo room. Torpedo is loaded, Sir. Captain: Click on continue button. Seaman: Aye Sir. [another long pause] Seaman: Is asking for target, Sir. Captain: Hmmm, is targeting Rainbow Warrior. Seaman: Aye Sir. Damn! Is saying torpedo is low on ink. Captain: Click ignore. We will get some ink when we return to base. Seaman: Aye Sir. We are ready to fire. Captain: Very good. You may fire when ready comrade. Seaman: Is firing torpedo, Sir. [another really long pause] Captain: Well? Seaman: Am trying Sir. Nothing is happening. Wait minute.... [a loud explosion is heard in the background followed by screaming on intercom] Captain: WTF was that?!?!? Seaman: Captain! New screen has appeared! "Outlook Express Fire Control has performed an illegal operation and will be shut down. "Click 'OK' to continue." Seaman: Oh my God! Paper clip has died! What should I do? Captain: Is shutting it down! Is shutting it down! Seaman: Is not responding Sir! Captain: Try 'CTRL-ALT-DELETE'! Seaman: Aye Sir. We are in luck! Task manager is still operating. I am instructing task manager to shut down Outlook Fire Control. [another long pause] Seaman: Task manager is saying that Outlook Fire Control is not responding. Captain: Well, no shit. Tell it to 'end task.' Seaman: Is happening nothing, Sir. Captain: Is trying 'CTRL-ALT-DELETE' again. Seaman: Aye Sir. [sounds of frantic pecking on keyboard.] Seaman: Oooh! Is pretty blue screen! Captain: Holy Shit! Not Blue Screen of Dea.... [KABLAM! A really big explosion. More screaming and the sound of rushing water.] The tape ends at this point. During the week long rescue effort, divers reported hearing tapping in the form of Morse code coming from survivors inside the damaged sub. The rescuers couldn't understand why a group of men would spend the last of their strength tapping out "Windows sucks" in Morse code. The tapes of the last moments of the Kursk may offer some insight into this. Where do you want to go today? Bottom of the Arctic Ocean okay with you? --------------82BB9BC9E1CA4AC80240C86E-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Oct 23 4:24:22 2000 Delivered-To: freebsd-chat@freebsd.org Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by hub.freebsd.org (Postfix) with ESMTP id 5122637B479 for ; Mon, 23 Oct 2000 04:24:19 -0700 (PDT) Received: from corto.lpt.ens.fr (corto.lpt.ens.fr [129.199.122.2]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id e9NBOFM04498 for ; Mon, 23 Oct 2000 13:24:15 +0200 (CEST) Received: from (rsidd@localhost) by corto.lpt.ens.fr (8.9.3/jtpda-5.3.1) id NAA26053 for freebsd-chat@freebsd.org; Mon, 23 Oct 2000 13:24:15 +0200 (CEST) Date: Mon, 23 Oct 2000 13:24:15 +0200 From: Rahul Siddharthan To: freebsd-chat@freebsd.org Subject: Free X servers for Windows? Message-ID: <20001023132415.L16719@lpt.ens.fr> Mail-Followup-To: freebsd-chat@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 3.4-STABLE i386 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all: Are there any good free X servers available for Windows? Any user experiences out there? If not, what are the good commercial ones? Thanks Rahul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Mon Oct 23 14:18:36 2000 Delivered-To: freebsd-chat@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 0E00337B4C5 for ; Mon, 23 Oct 2000 14:18:34 -0700 (PDT) Received: from wuerg (hmbdi7-212-144-176-050.arcor-ip.net [212.144.176.50]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id XAA00620 for ; Mon, 23 Oct 2000 23:18:30 +0200 (MET DST) Message-Id: <3.0.6.32.20001023232109.008a8c90@post.strato.de> X-Sender: webmaster%nightfire.de@post.strato.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 23 Oct 2000 23:21:09 +0200 To: chat@FreeBSD.org From: Olaf Hoyer Subject: Pictures (incl. daemonbabe) of BSD booth on german Linuxtag Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! on October 14th there was also a BSD booth present on the "Oldenburger Linuxtag". We did also a great deal in having a real, live mascot running around there ;-) OpenBSD folks already agreed that she's cute... Look at following adress: www.nightfire.de Regards Olaf Hoyer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 15: 2:26 2000 Delivered-To: freebsd-chat@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 4158437B479 for ; Tue, 24 Oct 2000 15:02:24 -0700 (PDT) Received: (qmail 9692 invoked by uid 1114); 24 Oct 2000 22:02:23 -0000 Date: 24 Oct 2000 15:02:23 -0700 Date: Tue, 24 Oct 2000 15:02:23 -0700 (PDT) From: Ceren Ercen To: chat@freebsd.org Cc: almus@dis.org Subject: Re: bondage bsd daemon image In-Reply-To: <20001023003635.B415D37B4C5@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For everyone that was interested in the Daemon-on-a-St.-Andrew's-cross Tshirt that was being talked about.... I talked with the maker of the shirt, and he's decided to do another run of them. Contact him if you want one (or more) at almus@dis.org. http://www.satindeath.net/boundchuck.jpg He's removing the mention of DefCon from the bottom of the shirt. And if anyone can come up with a better slogan than "The only way to lock up this OS", he's open to suggestions. -Ceren E. FreeBSD's "Strange Atractor." ceren@magnesium.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 15:20:22 2000 Delivered-To: freebsd-chat@freebsd.org Received: from exchserver.impact8.com (unknown [216.98.200.92]) by hub.freebsd.org (Postfix) with ESMTP id 34DD437B479 for ; Tue, 24 Oct 2000 15:20:20 -0700 (PDT) Received: by EXCHSERVER with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 16:16:40 -0600 Message-ID: <572C6148D69AD4119DEB00D0B765D10B040DC3@EXCHSERVER> From: Peter Kuyarov To: "'freebsd-chat@freebsd.org'" Subject: RE: bondage bsd daemon image Date: Tue, 24 Oct 2000 16:16:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can he also put this on the t-shirt? (I wanna wear this to a Linux expo/thingy) http://users.americanisp.net/~peterk/images/takeittux.jpg --- www.nul.cjb.net --- The Power to Crash --- www.FreeBSD.org --- The Power to Serve -----Original Message----- From: owner-freebsd-chat@FreeBSD.ORG [mailto:owner-freebsd-chat@FreeBSD.ORG]On Behalf Of Ceren Ercen Sent: Tuesday, October 24, 2000 4:02 PM To: chat@freebsd.org Cc: almus@dis.org Subject: Re: bondage bsd daemon image For everyone that was interested in the Daemon-on-a-St.-Andrew's-cross Tshirt that was being talked about.... I talked with the maker of the shirt, and he's decided to do another run of them. Contact him if you want one (or more) at almus@dis.org. http://www.satindeath.net/boundchuck.jpg He's removing the mention of DefCon from the bottom of the shirt. And if anyone can come up with a better slogan than "The only way to lock up this OS", he's open to suggestions. -Ceren E. FreeBSD's "Strange Atractor." ceren@magnesium.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 15:26: 4 2000 Delivered-To: freebsd-chat@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 71F3337B65E for ; Tue, 24 Oct 2000 15:26:00 -0700 (PDT) Received: (qmail 10958 invoked by uid 1114); 24 Oct 2000 22:25:58 -0000 Date: 24 Oct 2000 15:25:58 -0700 Date: Tue, 24 Oct 2000 15:25:58 -0700 (PDT) From: Ceren Ercen To: Peter Kuyarov Cc: "'freebsd-chat@freebsd.org'" , almus@dis.org Subject: RE: bondage bsd daemon image In-Reply-To: <572C6148D69AD4119DEB00D0B765D10B040DC3@EXCHSERVER> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 24 Oct 2000, Peter Kuyarov wrote: > Can he also put this on the t-shirt? (I wanna wear this to a Linux > expo/thingy) > http://users.americanisp.net/~peterk/images/takeittux.jpg That image was not approved by Kirk McKusick... so no, he won't. (and yes, that does mean that the other shirt has an "okay" from Kirk.) -Ceren E. FreeBSD's "Strange Attractor." ceren@magnesium.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 16:10: 4 2000 Delivered-To: freebsd-chat@freebsd.org Received: from kizmiaz.dis.org (kizmiaz.dis.org [216.240.45.60]) by hub.freebsd.org (Postfix) with ESMTP id 577B437B479 for ; Tue, 24 Oct 2000 16:10:01 -0700 (PDT) Received: from localhost (almus@localhost) by kizmiaz.dis.org (8.9.3/8.9.3) with SMTP id QAA24928 for ; Tue, 24 Oct 2000 16:10:01 -0700 (PDT) Date: Tue, 24 Oct 2000 16:09:59 -0700 (PDT) From: Almus To: freebsd-chat@freebsd.org Subject: Decided to join the list.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, since it appears my t-shirts have found some recognition in this list I figured I would join up. if you have any questions about them just ask.. (there are the shirts with "Chuck" bound to the St. Andrews cross) -Almus http://www.satindeath.net/ http://www.dis.org/ -- It is my Firm Belief that it's a mistake to hold Firm Beliefs! <-Goth.Code98-> almus@dis.org www.dis.org/almus uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT -- Send private encrypted e-mail - Freedom 1.1 www.zks.net/clickthrough/click.asp?partner_id=111 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 20:40:47 2000 Delivered-To: freebsd-chat@freebsd.org Received: from klapaucius.zer0.org (klapaucius.zer0.org [204.152.186.45]) by hub.freebsd.org (Postfix) with ESMTP id 01B6637B4C5 for ; Tue, 24 Oct 2000 20:40:42 -0700 (PDT) Received: by klapaucius.zer0.org (Postfix, from userid 1001) id D8F32239B7A; Tue, 24 Oct 2000 20:40:41 -0700 (PDT) Date: Tue, 24 Oct 2000 20:40:41 -0700 From: Gregory Sutter To: chat@freebsd.org Subject: More BSDcon pics Message-ID: <20001024204041.B41788@klapaucius.zer0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Zer0 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ...are available at http://www.zer0.org/pix/events/bsdcon-2000/ Greg -- Gregory S. Sutter Fnord. mailto:gsutter@zer0.org http://www.zer0.org/~gsutter/ hkp://wwwkeys.pgp.net/0x845DFEDD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 20:58: 0 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 53A2037B4C5 for ; Tue, 24 Oct 2000 20:57:58 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9P3ubh54849; Tue, 24 Oct 2000 22:56:37 -0500 (CDT) (envelope-from jlemon) Date: Tue, 24 Oct 2000 22:56:37 -0500 From: Jonathan Lemon To: Dan Kegel Cc: chat@freebsd.org Subject: kqueue Message-ID: <20001024225637.A54554@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently stumbled across a message you posted asking for microbenchmarks on kqueue. While I do think that microbenchmarks are partially misleading, I did run them on my machine for various numbers of connections, with varying number of active connections. The results are shown below. The results dovetail with what I expect: kqueue scales depending on the number of active connections that it sees, not with the total number of connections. Also, I presented a paper/talk at the recent BSDCon 2000, these are available at http://www.freebsd.org/~jlemon if you're interested. -- Jonathan This is on a single processor 600Mhz Pentium-III with 512MB of memory, running FreeBSD 4.x-STABLE: cache[10:13pm]> ./Poller_bench 5 1 spk XXX pipes 100 1000 10000 30000 select 54 - - - poll 50 552 11559 35178 kqueue 8 8 8 8 cache[10:13pm]> ./Poller_bench 5 10 spk XXX pipes 100 1000 10000 30000 select 100 - - - poll 95 571 11697 35499 kqueue 52 52 55 56 cache[10:13pm]> ./Poller_bench 5 50 spk XXX pipes 100 1000 10000 30000 select 299 - - - poll 287 887 12124 36054 kqueue 285 295 313 330 cache[10:13pm]> ./Poller_bench 5 100 spk XXX 14 microseconds to open each of 100 socketpairs pipes 100 1000 10000 30000 select 542 - - - poll 528 1091 12440 36530 kqueue 574 592 623 702 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 21:38:47 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 5210037B4C5 for ; Tue, 24 Oct 2000 21:38:45 -0700 (PDT) Received: from alumni.caltech.edu ([63.201.176.178]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G2Y00G4ZY6GH0@mta5.snfc21.pbi.net> for chat@freebsd.org; Tue, 24 Oct 2000 21:37:29 -0700 (PDT) Date: Tue, 24 Oct 2000 21:45:14 -0700 From: Dan Kegel Subject: Re: kqueue microbenchmark results To: Jonathan Lemon Cc: chat@freebsd.org, linux-kernel@vger.kernel.org Reply-To: dank@alumni.caltech.edu Message-id: <39F6655A.353FD236@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20001024225637.A54554@prism.flugsvamp.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Johnathan, Thanks for running that test for me! I've added your results (plus a cautionary note about microbenchmarks and a link to your site) to http://www.kegel.com/dkftpbench/Poller_bench.html If you haven't already, you might peek at the discussion on linux-kernel. Linus seems to be on the verge of adding something like kqueue() to Linux, but appears opposed to supporting level-triggering; he likes the simplicity of edge triggering (from the kernel's point of view!). See http://boudicca.tux.org/hypermail/linux-kernel/2000week44/index.html#9 Thanks, Dan Jonathan Lemon wrote: > I recently stumbled across a message you posted asking for > microbenchmarks on kqueue. While I do think that microbenchmarks > are partially misleading, I did run them on my machine for > various numbers of connections, with varying number of active > connections. The results are shown below. > > The results dovetail with what I expect: kqueue scales depending > on the number of active connections that it sees, not with the > total number of connections. > > Also, I presented a paper/talk at the recent BSDCon 2000, these > are available at http://www.freebsd.org/~jlemon if you're interested. > -- > Jonathan > > This is on a single processor 600Mhz Pentium-III with 512MB of > memory, running FreeBSD 4.x-STABLE: [ 1 active pipe ] > cache[10:13pm]> ./Poller_bench 5 1 spk 100 1000 10000 30000 > pipes 100 1000 10000 30000 > select 54 - - - > poll 50 552 11559 35178 > kqueue 8 8 8 8 [ 10 active pipes ] > cache[10:13pm]> ./Poller_bench 5 10 spk 100 1000 10000 30000 > pipes 100 1000 10000 30000 > select 100 - - - > poll 95 571 11697 35499 > kqueue 52 52 55 56 [ 100 active pipes ] > cache[10:13pm]> ./Poller_bench 5 100 spk 100 1000 10000 30000 > pipes 100 1000 10000 30000 > select 542 - - - > poll 528 1091 12440 36530 > kqueue 574 592 623 702 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Tue Oct 24 23: 4:17 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3F6DC37B479 for ; Tue, 24 Oct 2000 23:04:07 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9P62kh58482; Wed, 25 Oct 2000 01:02:46 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 01:02:46 -0500 From: Jonathan Lemon To: Dan Kegel Cc: Jonathan Lemon , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025010246.B57913@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <39F6655A.353FD236@alumni.caltech.edu> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Oct 24, 2000 at 09:45:14PM -0700, Dan Kegel wrote: > If you haven't already, you might peek at the discussion on > linux-kernel. Linus seems to be on the verge of adding > something like kqueue() to Linux, but appears opposed to > supporting level-triggering; he likes the simplicity of > edge triggering (from the kernel's point of view!). See > http://boudicca.tux.org/hypermail/linux-kernel/2000week44/index.html#9 Yes, someone pointed me to those today. I would suggest reading some of the relevant literature before embarking on a design. My paper discusses some of the issues, and Mogul/Banga make some good points too. While an 'edge-trigger' design is indeed simpler, I feel that it ends up making the job of the application harder. A simple example to illustrate the point: what if the application does not choose to read all the data from an incoming packet? The app now has to implement its own state mechanism to remember that there may be pending data in the buffer, since it will not get another event notification unless another packet arrives. kqueue() provides the ability for the user to choose which model suits their needs better, in keeping with the unix philosophy of tools, not policies. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 2: 6: 2 2000 Delivered-To: freebsd-chat@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9A73E37B479 for ; Wed, 25 Oct 2000 02:05:59 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA49843; Wed, 25 Oct 2000 11:04:59 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Ceren Ercen Cc: Peter Kuyarov , "'freebsd-chat@freebsd.org'" , almus@dis.org Subject: Re: bondage bsd daemon image References: From: Dag-Erling Smorgrav Date: 25 Oct 2000 11:04:59 +0200 In-Reply-To: Ceren Ercen's message of "24 Oct 2000 15:25:58 -0700, Tue, 24 Oct 2000 15:25:58 -0700 (PDT)" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ceren Ercen writes: > On Tue, 24 Oct 2000, Peter Kuyarov wrote: > > http://users.americanisp.net/~peterk/images/takeittux.jpg > That image was not approved by Kirk McKusick... so no, he won't. Unfortunately, anybody wishing to print T-shirts with that image may be able to successfully argue that it's a work of satire, and therefore fair use, no matter what Kirk thinks. (personally, I find it amusing, but I think it's needlessly offensive to Linux users) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 8:27:26 2000 Delivered-To: freebsd-chat@freebsd.org Received: from oof.netnation.com (040imtd196.chartermi.net [24.247.40.196]) by hub.freebsd.org (Postfix) with ESMTP id CA5D037B479 for ; Wed, 25 Oct 2000 08:27:23 -0700 (PDT) Received: from sim by oof.netnation.com with local (Exim 3.16 #1 (Debian)) id 13oSSL-0000P4-00; Wed, 25 Oct 2000 11:27:09 -0400 Date: Wed, 25 Oct 2000 11:27:09 -0400 From: Simon Kirby To: Jonathan Lemon Cc: Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025112709.A1500@stormix.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025010246.B57913@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Oct 25, 2000 at 01:02:46AM -0500 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote: > Yes, someone pointed me to those today. I would suggest reading > some of the relevant literature before embarking on a design. My > paper discusses some of the issues, and Mogul/Banga make some good > points too. > > While an 'edge-trigger' design is indeed simpler, I feel that it > ends up making the job of the application harder. A simple example > to illustrate the point: what if the application does not choose > to read all the data from an incoming packet? The app now has to > implement its own state mechanism to remember that there may be pending > data in the buffer, since it will not get another event notification > unless another packet arrives. What applications would do better by postponing some of the reading? I can't think of any reason off the top of my head why an application wouldn't want to read everything it can. Doing everything in smaller chunks would increase overhead (but maybe reduce latencies very slightly -- albeit probably not much when using a get_events()-style interface). Isn't it probably better to keep the kernel implementation as efficient as possible so that the majority of applications which will read (and write) all data possible can do it as efficiently as possible? Queueing up the events, even as they are in the form received from the kernel, is pretty simple for a userspace program to do, and I think it's the best place for it. I know nothing about any other implementations, though, and I'm speaking mainly from the experiences I've had with coding daemons using select(). You mention you wrote a paper discussing this issue...Where could I find this? Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 8:28:40 2000 Delivered-To: freebsd-chat@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id EF17937B4C5 for ; Wed, 25 Oct 2000 08:28:24 -0700 (PDT) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id JAA19414; Wed, 25 Oct 2000 09:28:13 -0600 (MDT) Message-Id: <4.3.2.7.2.20001025092326.046f5ed0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Oct 2000 09:28:04 -0600 To: Ceren Ercen , chat@FreeBSD.ORG From: Brett Glass Subject: Re: bondage bsd daemon image Cc: almus@dis.org In-Reply-To: References: <20001023003635.B415D37B4C5@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:02 PM 10/24/2000, Ceren Ercen wrote: >http://www.satindeath.net/boundchuck.jpg > >He's removing the mention of DefCon from the bottom of the shirt. And if >anyone can come up with a better slogan than "The only way to lock up this >OS", he's open to suggestions. How about: "If only I could get myself unchained from X Windows...." In any case, he should remove the space between "FREE" and "BSD", or (better) use the canonical mixed-case spelling ("FreeBSD"). --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 10: 9:13 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by hub.freebsd.org (Postfix) with ESMTP id 128FF37B4C5 for ; Wed, 25 Oct 2000 10:09:11 -0700 (PDT) Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id TAA14791; Wed, 25 Oct 2000 19:08:58 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id TAA02527; Wed, 25 Oct 2000 19:08:48 +0200 Date: Wed, 25 Oct 2000 19:08:48 +0200 From: Jamie Lokier To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025190848.C2266@pcep-jamie.cern.ch> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025112709.A1500@stormix.com>; from sim@stormix.com on Wed, Oct 25, 2000 at 11:27:09AM -0400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Simon Kirby wrote: > > While an 'edge-trigger' design is indeed simpler, I feel that it > > ends up making the job of the application harder. A simple example > > to illustrate the point: what if the application does not choose > > to read all the data from an incoming packet? The app now has to > > implement its own state mechanism to remember that there may be pending > > data in the buffer, since it will not get another event notification > > unless another packet arrives. > > What applications would do better by postponing some of the reading? > I can't think of any reason off the top of my head why an application > wouldn't want to read everything it can. Pipelined server. 1. Wait for event. 2. Read block 3. If EAGAIN, goto 1. 4. If next request in block is incomplete, goto 2. 5. Process next request in block. 6. Write response. 7. If EAGAIN, wait until output is ready for writing then goto 6. 8. Goto 1 or 2, your choice. (Here I'd go to 2 if the last read was complete -- it avoids a redundant call to poll()). If you simply read everything you can at step 2, you'll run out of memory the moment someone sends you 100000 requests. This doesn't happen if you leave unread data in kernel space -- TCP windows and all that. enjoy, -- Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 10:24:49 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 389CA37B4CF for ; Wed, 25 Oct 2000 10:24:45 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9PHN7f79089; Wed, 25 Oct 2000 12:23:07 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 12:23:07 -0500 From: Jonathan Lemon To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025122307.B78130@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001025112709.A1500@stormix.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote: > On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote: > > > Yes, someone pointed me to those today. I would suggest reading > > some of the relevant literature before embarking on a design. My > > paper discusses some of the issues, and Mogul/Banga make some good > > points too. > > > > While an 'edge-trigger' design is indeed simpler, I feel that it > > ends up making the job of the application harder. A simple example > > to illustrate the point: what if the application does not choose > > to read all the data from an incoming packet? The app now has to > > implement its own state mechanism to remember that there may be pending > > data in the buffer, since it will not get another event notification > > unless another packet arrives. > > What applications would do better by postponing some of the reading? > I can't think of any reason off the top of my head why an application > wouldn't want to read everything it can. Doing everything in smaller > chunks would increase overhead (but maybe reduce latencies very slightly > -- albeit probably not much when using a get_events()-style interface). Consider a program which reads from point A, writes to point B. If the buffer associated with B fills up, then we don't want to continue reading from A. A/B may be network sockets, pipes, or ptys. Or perhaps you receive a request to use a resource that is currently busy. Does your application want to postpone the request, or read the data immediately, even if the request can't be serviced yet? My point is that I can easily think of several examples as to where this behavior may be beneficial to the application, and I use some of them myself. You can indeed get the same result by forcing each and every application that wants this behavior to implement their own tracking mechanism, but this strikes me as error-prone and places an undue burden on the application programmer. > Isn't it probably better to keep the kernel implementation as efficient > as possible so that the majority of applications which will read (and > write) all data possible can do it as efficiently as possible? Queueing > up the events, even as they are in the form received from the kernel, is > pretty simple for a userspace program to do, and I think it's the best > place for it. I don't believe that you must sacrifice efficiency to achieve this goal, I think that you can provide both forms in an efficent fashion. > I know nothing about any other implementations, though, and I'm speaking > mainly from the experiences I've had with coding daemons using select(). > You mention you wrote a paper discussing this issue...Where could I find > this? I'm also speaking from experience, from using various forms of event notification. kqueue() is actually a 3rd generation system, building off the experience I had with the first two, along with other input. You can find my paper at http://people.freebsd.org/~jlemon -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 11:35:28 2000 Delivered-To: freebsd-chat@freebsd.org Received: from peace.netnation.com (peace.netnation.com [204.174.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 8F35037B479 for ; Wed, 25 Oct 2000 11:35:25 -0700 (PDT) Received: from sim by peace.netnation.com with local (Exim 3.13 #5) id 13oVOS-0003Id-00; Wed, 25 Oct 2000 11:35:20 -0700 Date: Wed, 25 Oct 2000 11:35:20 -0700 From: Simon Kirby To: Jamie Lokier Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025113520.E12064@stormix.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025190848.C2266@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001025190848.C2266@pcep-jamie.cern.ch>; from lk@tantalophile.demon.co.uk on Wed, Oct 25, 2000 at 07:08:48PM +0200 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 07:08:48PM +0200, Jamie Lokier wrote: > Simon Kirby wrote: > > > What applications would do better by postponing some of the reading? > > I can't think of any reason off the top of my head why an application > > wouldn't want to read everything it can. > > Pipelined server. > > 1. Wait for event. > 2. Read block > 3. If EAGAIN, goto 1. > 4. If next request in block is incomplete, goto 2. > 5. Process next request in block. > 6. Write response. > 7. If EAGAIN, wait until output is ready for writing then goto 6. > 8. Goto 1 or 2, your choice. > (Here I'd go to 2 if the last read was complete -- it avoids a > redundant call to poll()). > > If you simply read everything you can at step 2, you'll run out of > memory the moment someone sends you 100000 requests. > > This doesn't happen if you leave unread data in kernel space -- > TCP windows and all that. Hmm, I don't understand. What happens at "wait until output is ready for writing then goto 6"? You mean you would stop the main loop to wait for a single client to unclog? Wouldn't you just do this? -> 1. Wait for event (read and write queued). Event occurs: Incoming data available. 2. Read a block. 3. Process block just read: Does it contain a full request? If not, queue, goto 2, munge together. If no more data, queue beginning of request, if any, and goto 1. 4. Walk over available requests in block just read. Process. 5. Attempt to write response, if any. 6. Attempted write: Did it all get out? If not, queue waiting writable data and goto 1 to wait for a write event. 7. Goto 2. Assume we got write clogged. Some loop later: 10. Wait for event (read and write queued). Event occurs: Write space available. 11. Write remaining available data. 12. Attempted write: Did it all get out? If not, queue remaining writable data and goto 1 to wait for another write event. 13. Goto 2. (If we're some sort of forwarding daemon and the receiving end of our forward has just unclogged, we want to read any readable data we had waiting. Same with if we're just answering a request, though, as the send direction could still get clogged.) What can't you do here? What's wrong? Note that the write event will let you read any remaining queued data. If you actually stop from going back to the main loop when you're write clogged, you will pause the daemon and create an easy DoS problem. There's no way around needing to queue writable data at least. This is how I wrote my irc daemon a while back, and it works fine with select(). I can't see what wouldn't work with edge-triggered events except perhaps the write() event -- I'm not sure what would be considered "triggered", perhaps when it goes under a watermark or something. In any case, it should all still work assuming get_events() offers the ability to receive "write space available" events. You don't have to read all data if you don't want to, assuming you will get another event later that will unclog the situation (meaning the obstacle must also trigger an event when it is cleared). In fact, if you did leave the read queued in a daemon using select() before, you'd keep looping endlessly taking all CPU and never idle because there would always be read data available. You'd have to not queue the descriptor into the read set and instead stick it in the write set so that you can sleep waiting for the write set to become available, effectively ignorning any further events on the read set until the write unclogs. This sounds just like what would happen if you only got one notification (edge triggered) in the first place. Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 11:40:32 2000 Delivered-To: freebsd-chat@freebsd.org Received: from peace.netnation.com (peace.netnation.com [204.174.223.2]) by hub.freebsd.org (Postfix) with ESMTP id A643F37B479 for ; Wed, 25 Oct 2000 11:40:29 -0700 (PDT) Received: from sim by peace.netnation.com with local (Exim 3.13 #5) id 13oVTQ-00059Q-00; Wed, 25 Oct 2000 11:40:28 -0700 Date: Wed, 25 Oct 2000 11:40:28 -0700 From: Simon Kirby To: Jonathan Lemon Cc: Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025114028.F12064@stormix.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001025122307.B78130@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Oct 25, 2000 at 12:23:07PM -0500 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote: > Consider a program which reads from point A, writes to point B. If > the buffer associated with B fills up, then we don't want to continue > reading from A. > > A/B may be network sockets, pipes, or ptys. Fine, but we can bind the event watching to the device or socket or pipe that will clog up, right? In which case, we'll later get a write event (just like with select()), and then once there is some progress you can go back to read()ing from the original descriptor. This is even easier than using select() because you don't have to take the descriptor out of the read set and put it in the write set temporarily -- it will automatically work that way. > Or perhaps you receive a request to use a resource that is currently > busy. Does your application want to postpone the request, or read the > data immediately, even if the request can't be serviced yet? Assuming this "resource" has a way of waking up the process when it unclogs, then you can go back and read the remaining data later, which is what you would want to do anyway. > My point is that I can easily think of several examples as to where > this behavior may be beneficial to the application, and I use some of > them myself. You can indeed get the same result by forcing each and > every application that wants this behavior to implement their own > tracking mechanism, but this strikes me as error-prone and places an > undue burden on the application programmer. I can see that you could write it this way... I'm just trying to see if it's really needed. :) As I wrote in my last email to Jamie, you would need to implement a tracking mechanism in any case to avoid DoS attacks from clients or a case where a single client can clog up the reading from any other client. And you'd need to take the descriptor out of the read() set in the select() case anyway, so I don't really see what's different. > You can find my paper at http://people.freebsd.org/~jlemon I'll go and read it now. :) Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 12:36:46 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by hub.freebsd.org (Postfix) with ESMTP id 04A4737B479 for ; Wed, 25 Oct 2000 12:36:41 -0700 (PDT) Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA15213; Wed, 25 Oct 2000 21:36:10 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id VAA04193; Wed, 25 Oct 2000 21:36:10 +0200 Date: Wed, 25 Oct 2000 21:36:10 +0200 From: Jamie Lokier To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Efficient edge-triggered event interface Message-ID: <20001025213610.A3685@pcep-jamie.cern.ch> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025190848.C2266@pcep-jamie.cern.ch> <20001025113520.E12064@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025113520.E12064@stormix.com>; from sim@stormix.com on Wed, Oct 25, 2000 at 11:35:20AM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This text is about how edge-triggered events can work, but they must be the right kind of edges if they are to be efficient. With suggestions. Simon Kirby wrote: > What happens at "wait until output is ready for writing then goto 6"? > You mean you would stop the main loop to wait for a single client to > unclog? I mean stop *just this state machine*. Go back to the main loop to process the others. What I wrote was a simplification. The precise condition can be complicated. You probably want to process some more requests from the same client even while the output is blocked, so that you have a few responses ready when it unblocks. Also, you may wish to base the decision of how many requests/responses are taking up your memory on more global things, like how full are your buffers for other clients. > Wouldn't you just do this? -> > > 1. Wait for event (read and write queued). Event occurs: Incoming > data available. > 2. Read a block. > 3. Process block just read: Does it contain a full request? If not, > queue, goto 2, munge together. If no more data, queue beginning > of request, if any, and goto 1. > 4. Walk over available requests in block just read. Process. Care in step 4. Processing all the requests may generate more data than you're prepared to buffer. > 5. Attempt to write response, if any. > 6. Attempted write: Did it all get out? If not, queue waiting > writable data and goto 1 to wait for a write event. I'd attempt to write() responses as each request is processed, if the responses are large ones. E.g. files over http. For small ones, multiple responses are coalesced in the per-connection output buffer. Now, about events models. Writes and edge-triggered events -------------------------------- The write event would be edge-triggered by write becoming possible after it wasn't possible. I.e., the transition from when write() would return EGAIN to when it wouldn't. That's fine for both our servers I think. Just as with select/poll, the server can choose to retain a flag saying whether the socket can be written to, to avoid redundant write() system calls. However it doesn't have to do this, edge-triggered events will work without it. Reads and edge-triggered events ------------------------------- It doesn't matter to receive unnecessary events, but of course we prefer to avoid redundant events. We _must_ receive events whenever data becomes available if the application's state machine decides to wait for one. Choice of two obvious rules: 1. Event whenever input buffer switches from empty to non-empty. 2. Event whenever new data arrives. Rule 1 is the sane, obvious one that corresponds with poll() semantics. Unfortunately it has an overhead. As an application, I have to ensure I don't ever wait unless I _know_ that the input buffer is empty. That means I must not wait on a descriptor until read() has returned EAGAIN. Seems reasonable -- but it's actually more system calls than a select/poll loop. Why? With select/poll, if I call read() and get a short result, it's good to assume the next read() call is *likely* to return EAGAIN. In other words I will go back to the main loop and wait until select/poll reports POLLIN, rather than trying a second read(). That's select/read/write per transaction. Rule 1 would force me to do kevent/read/read/write per transaction. When you're down to 3 system calls, one more is significant. Rule 2 guarantees to wake me up, but it has a big overhead. If more and more new data arrives but I don't want to read it right now, either I'm going to receive events which I ignore, or I must call bind_event() twice for the interval when I'm not interested. I receive lots of events because I'm calling kevent() to process _other_ descriptors many times in my main loop before I'm ready to read this one. This is unnecessary overhead -- I already know there is more data. So, is there a rule 3? One which fits my model (minimum system calls) is: 3. Condition 1 + also when read() does not consume the whole buffer. Pros: - Minimum system calls - Avoids "NOTPOLLIN" events, as someone suggested. - Interface is still beautiful and simple. I'll leave it to our top API designer to decide. enjoy, -- Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 12:40:58 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by hub.freebsd.org (Postfix) with ESMTP id 4D3D137B479 for ; Wed, 25 Oct 2000 12:40:56 -0700 (PDT) Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA28750; Wed, 25 Oct 2000 21:40:53 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id VAA04247; Wed, 25 Oct 2000 21:40:53 +0200 Date: Wed, 25 Oct 2000 21:40:53 +0200 From: Jamie Lokier To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025214053.C3685@pcep-jamie.cern.ch> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025114028.F12064@stormix.com>; from sim@stormix.com on Wed, Oct 25, 2000 at 11:40:28AM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Simon Kirby wrote: > And you'd need to take the descriptor out of the read() set in the > select() case anyway, so I don't really see what's different. The difference is that taking a bit out of select()'s bitmap is basically free. Whereas the equivalent with events is a bind_event() system call. -- Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 13:47:28 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id E6AAA37B479 for ; Wed, 25 Oct 2000 13:47:22 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA15786; Wed, 25 Oct 2000 13:25:17 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAAUsa47A; Wed Oct 25 13:21:29 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id NAA29899; Wed, 25 Oct 2000 13:24:18 -0700 (MST) From: Terry Lambert Message-Id: <200010252024.NAA29899@usr01.primenet.com> Subject: Re: kqueue microbenchmark results To: sim@stormix.com (Simon Kirby) Date: Wed, 25 Oct 2000 20:24:18 +0000 (GMT) Cc: jlemon@flugsvamp.com (Jonathan Lemon), dank@alumni.caltech.edu (Dan Kegel), chat@FreeBSD.ORG, linux-kernel@vger.kernel.org In-Reply-To: <20001025112709.A1500@stormix.com> from "Simon Kirby" at Oct 25, 2000 11:27:09 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What applications would do better by postponing some of the reading? > I can't think of any reason off the top of my head why an application > wouldn't want to read everything it can. Doing everything in smaller > chunks would increase overhead (but maybe reduce latencies very slightly > -- albeit probably not much when using a get_events()-style interface). Applications that: o Want to limit their memory footprint by limiting the amount of process VM they consume, and so limit their buffer size to less than all the data the stacks might be capable of providing at one time o With fixed-size messages, which want to operate on a message at a time, without restricting the sender to sending only a single message or whole messages at one time o Want to limit their overall system processing overhead for irrelevent/stale data (example: one which implements state delta referesh events, such as "Bolo" or "Netrek") o Have to implement "leaky bucket" algorithms, where it is permissible to drop some data on the floor, and assume it will be retransmited later (e.g. ATM or user space protocols which want to implement QoS guarantees) o Need to take advantage of kernel strategies for protection from denial of service attacks, without having to redo those strategies themselves (particularly, flood attacks; this is the same reason inetd supports connection rate limiting on behalf of the programs it is responsible for starting) o With multiple data channels to which they are listening, some of which are more important than others (e.g. the Real Networks streaming media protocols are an example) o Want to evealuate the contents of a security negotiation prior to accepting data that was sent using an expired certificate or otherwise bogus credentials There are all sorts of good reasons a programmer would want to trust the kernel, instead of having to build ring buffers into each and every program they write to ensure they remember data which is irrelevent to the processing at hand, or protect their code against buffer overflows initiated by trusted applications. > Isn't it probably better to keep the kernel implementation as efficient > as possible so that the majority of applications which will read (and > write) all data possible can do it as efficiently as possible? Queueing > up the events, even as they are in the form received from the kernel, is > pretty simple for a userspace program to do, and I think it's the best > place for it. Reading, yes. Writing, no. The buffers they are filling in the kernel belong to the kernel, not the application, despite what Microsoft tells you about WSOCK32 programming. The WSOCK32 model assumes that the networking is implemented in another user space process, rather than in the kernel. People who use the "async" WSOCK32 interface rarely understand the implications because they rarely understand how async messages are built using a Windows data pump, which serializes all requests through the moral equivalent of a select loop (which is why NT supports async notification on socket I/O, but other versions of Windows does not [NB: actually, it could, using an fd=-1 I/O completion port, but the WSOCK32 programmers were a bit lazy and were also being told to keep performance under that of NT]). In any case, it's not just a matter of queueing up kernel events, it's also a matter of partially instead of completely reacting to the events, since if an event comes in that says you have 1k of data, and you only read 128 bytes of it, you will have to requeue, in LIFO instead of FIFO order, a modified event with 1k-128 bytes, so the next read completes as expected. Very gross code, which must be then duplicated in every iser space program, and either requires a "tail minus one" pointer, or requires doubly linking the user space event queue. > I know nothing about any other implementations, though, and I'm speaking > mainly from the experiences I've had with coding daemons using select(). Programs which are select-based are usually DFAs (Deterministic Finite State Automatons), which operate on non-blocking file descriptors. This means that I/O is not interleaved, and so is not necessarily as efficient as it could be, should there ever occur a time when an I/O completion posts sooner after being checked than the amount of time it takes to complete 50% of an event processing cycle (the reasons for this involve queueing theory algebra, and are easier to explain in terms of the relative value of positive and negative caches in situations where a cache miss results in the need to perform a linear traversal). A lot of this can be "magically" alleviated using POSIX AIO calls in the underlying implementation, instead of relying on non-blocking I/O -- even then, don't expect a better than 50% improvement, and be prepared for it to be closer to 30%-40%. Expect kernel threads to max out at less than 50% (and usually be closer to 25%-35%), and expect kernel threads on any non-commercial OS and on SVR4 systems, excluding the most recent versions of Solaris, to do much worse than that. Really, the performance of DFAs based on select loops has more to do with mean processing time for any arbitrary event, than anything else. I was able to run logins for an entire lab full of X terminals with an xdm replacement DFA that was very highly controlled in its longhest and mean path processing latency, and recover the use of a SPARCServer that was otherwise burning all its VM and CPU resources on swapping 32 copies of xdm in and out for no good reason. The AfterBurner web server (John Sokol, et. al.) is still, I believe, the highest performance HTTP server, by a wide margin, beating out anything threads or not DFA-based, like it is. Even kqueue and kernel threads are DFAs, in the limit: the question is on which side of the user/kernel barrier the code lives, not whether or not it lives somewhere. All UNIX schedulers (well, all reasonable and deployed-for-actual-work ones) are DFAs in disguise. > You mention you wrote a paper discussing this issue...Where could I find > this? I'm pretty sure he will give you the paper reference; I personally don't have the reference handy (sorry). I think this is more a case of believing the weight of the literature, rather than an individual report, so you will want to look at his paper, but also at others in the field, before you decide to believe anything specific (though I have no doubt you'll agree with his findings, after you do that). Otherwise, it's just him against Linus, and making a decision based on one paper or an authors reputation is bad science (and bad engineering). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 14:36:51 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id DC58537B479 for ; Wed, 25 Oct 2000 14:36:48 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9PLZCc87745; Wed, 25 Oct 2000 16:35:12 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 16:35:12 -0500 From: Jonathan Lemon To: Jamie Lokier Cc: Simon Kirby , Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025163512.A87091@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> <20001025214053.C3685@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001025214053.C3685@pcep-jamie.cern.ch> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 09:40:53PM +0200, Jamie Lokier wrote: > Simon Kirby wrote: > > And you'd need to take the descriptor out of the read() set in the > > select() case anyway, so I don't really see what's different. > > The difference is that taking a bit out of select()'s bitmap is > basically free. Whereas the equivalent with events is a bind_event() > system call. With the caveat that kevent() will take a changelist at the same time that it returns an eventlist, so while you do incur some kernel processing to temporarily disable the descriptor, the system call is essentially free. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 14:57:56 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3392837B4C5 for ; Wed, 25 Oct 2000 14:57:53 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9PLuQ988412; Wed, 25 Oct 2000 16:56:26 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 16:56:26 -0500 From: Jonathan Lemon To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025165626.B87091@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001025114028.F12064@stormix.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 11:40:28AM -0700, Simon Kirby wrote: > On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote: > > > Consider a program which reads from point A, writes to point B. If > > the buffer associated with B fills up, then we don't want to continue > > reading from A. > > > > A/B may be network sockets, pipes, or ptys. > > Fine, but we can bind the event watching to the device or socket or pipe > that will clog up, right? In which case, we'll later get a write event > (just like with select()), and then once there is some progress you can > go back to read()ing from the original descriptor. This is even easier > than using select() because you don't have to take the descriptor out of > the read set and put it in the write set temporarily -- it will > automatically work that way. Yes, but with the above, you can't use get_event() as your main dispatching loop to do the read() call any more, since there may be no notifications pending in the queue. So you have to expand your main loop to include both get_event() as well as walk the "these descriptors may have partial data" list. Also, as Jamie pointed out, with kqueue/select you can do: kevent/read/write while with a pure edge-triggered scheme, you either must do: bind_event/read/.../read == 0/write Or maintain your own "this descriptor may have data" list. Also, consider the following scenario for the proposed get_event(): 1. packet arrives, queues an event. 2. user retrieves event. 3. second packet arrives, queues event again. 4. user reads() all data. Now, next time around the loop, we get a notification for an event when there is no data to read. The application now must be prepared to handle this case (meaning no blocking read() calls can be used). Also, what happens if the user closes the socket after step 4 above? The user now receives a notification for a fd which no longer exists, or possibly has been reused for another connection. This may or may not make a difference to the application, but it must be prepared to handle it anyway. I believe that Zack Brown ran into this problem with one of the webservers he was writing. > > You can find my paper at http://people.freebsd.org/~jlemon > > I'll go and read it now. :) The paper talks about some of the issues we have been discussing, as well as the design rationale behind kqueue. I'd be happy to answer any questions about the paper. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 15:11:39 2000 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (unknown [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 9CA3C37B4D7 for ; Wed, 25 Oct 2000 15:11:38 -0700 (PDT) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 25 Oct 2000 15:11:08 -0700 From: "David Schwartz" To: "Jonathan Lemon" , "Simon Kirby" Cc: "Dan Kegel" , , Subject: RE: kqueue microbenchmark results Date: Wed, 25 Oct 2000 15:11:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001025165626.B87091@prism.flugsvamp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Now, next time around the loop, we get a notification for an event > when there is no data to read. The application now must be prepared > to handle this case (meaning no blocking read() calls can be used). > -- > Jonathan If the programmer never wants to block in a read call, he should never do a blocking read anyway. There's no standard that requires readability at time X to imply readability at time X+1. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 15:28:35 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D2AFB37B4CF for ; Wed, 25 Oct 2000 15:28:33 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9PMR2s89738; Wed, 25 Oct 2000 17:27:02 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 17:27:02 -0500 From: Jonathan Lemon To: David Schwartz Cc: Jonathan Lemon , Simon Kirby , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025172702.B89038@prism.flugsvamp.com> References: <20001025165626.B87091@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote: > > > Now, next time around the loop, we get a notification for an event > > when there is no data to read. The application now must be prepared > > to handle this case (meaning no blocking read() calls can be used). > > -- > > Jonathan > > If the programmer never wants to block in a read call, he should never do a > blocking read anyway. There's no standard that requires readability at time > X to imply readability at time X+1. Quite true on the surface. But taking that statement at face value implies that it is okay for poll() to return POLLIN on a descriptor even if there is no data to be read. I don't think this is the intention. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 15:34:14 2000 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (unknown [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id DC75737B4CF for ; Wed, 25 Oct 2000 15:34:08 -0700 (PDT) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 25 Oct 2000 15:33:38 -0700 From: "David Schwartz" To: "Jonathan Lemon" Cc: , Subject: RE: kqueue microbenchmark results Date: Wed, 25 Oct 2000 15:34:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001025172702.B89038@prism.flugsvamp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote: > > > > > Now, next time around the loop, we get a notification for an event > > > when there is no data to read. The application now must be prepared > > > to handle this case (meaning no blocking read() calls can be used). > > > -- > > > Jonathan > > > > If the programmer never wants to block in a read call, he > > should never do a > > blocking read anyway. There's no standard that requires > > readability at time > > X to imply readability at time X+1. > > Quite true on the surface. But taking that statement at face value > implies that it is okay for poll() to return POLLIN on a descriptor > even if there is no data to be read. I don't think this is the intention. Never mind what it implies. Just stick to what it says. :) In my opinion, it's perfectly reasonable for an implementation to show POLLIN on a call to poll() and then later block in read(). As far as I know no implementation does this, but no standard prevents an implementation from, for example, swapping out received TCP to disk if it's not retrieved and blocking later when you ask for the data until it can get the data back. I would even argue that it's possible for an implementation to decide that a connection had errored (for example, due to a timeout) and signalling POLLIN. Then before you call 'read', it gets a packet and decides that the connection is actually fine and so blocks in 'read'. This wouldn't seem possible in TCP, but it's possible to imagine protocols where it's sensible to do. And again, as far as I know, no standard prohibits it. If a programmer does not ever wish to block under any circumstances, it's his obligation to communicate this desire to the implementation. Otherwise, the implementation can block if it doesn't have data or an error available at the instant 'read' is called, regardless of what it may have known or done in the past. It's also just generally good programming practice. There was a time when many operating systems had bugs that caused 'select loop' type applications to hang if they didn't set all their descriptors non-blocking. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 16:18:45 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3710F37B4C5 for ; Wed, 25 Oct 2000 16:18:39 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9PNIbo00948; Wed, 25 Oct 2000 16:18:37 -0700 (PDT) Date: Wed, 25 Oct 2000 16:18:37 -0700 From: Alfred Perlstein To: David Schwartz Cc: Jonathan Lemon , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025161837.D28123@fw.wintelcom.net> References: <20001025172702.B89038@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from davids@webmaster.com on Wed, Oct 25, 2000 at 03:34:08PM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Schwartz [001025 15:35] wrote: > > If a programmer does not ever wish to block under any circumstances, it's > his obligation to communicate this desire to the implementation. Otherwise, > the implementation can block if it doesn't have data or an error available > at the instant 'read' is called, regardless of what it may have known or > done in the past. It's also just generally good programming practice. There > was a time when many operating systems had bugs that caused 'select loop' > type applications to hang if they didn't set all their descriptors > non-blocking. Yes, and as you mentioned, it was _bugs_ in the operating system that did this. I don't think it's wise to continue speculating on this issue unless you can point to a specific document that says that it's OK for this type of behavior to happen. Let's take a look at the FreeBSD manpage for poll: POLLIN Data other than high priority data may be read without blocking. ok no one bothers to do *BSD compat anymore (*grumble*), so, Solaris: POLLIN Data other than high priority data may be read without blocking. For STREAMS, this flag is set in revents even if the message is of zero length. I see a trend here, let's try Linux: #define POLLIN 0x0001 /* There is data to read */ This seems to imply that it is one hell of a bug to block, returning an error would be acceptable, but surely not blocking. I know manpages are a poor source for references but you're the one putting up a big fight for blocking behavior from poll, perhaps you can point out a standard that contradicts the manpages? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 17: 5:17 2000 Delivered-To: freebsd-chat@freebsd.org Received: from kizmiaz.dis.org (kizmiaz.dis.org [216.240.45.60]) by hub.freebsd.org (Postfix) with ESMTP id 1164037B479 for ; Wed, 25 Oct 2000 17:05:15 -0700 (PDT) Received: from localhost (almus@localhost) by kizmiaz.dis.org (8.9.3/8.9.3) with SMTP id RAA06209; Wed, 25 Oct 2000 17:04:50 -0700 (PDT) Date: Wed, 25 Oct 2000 17:04:49 -0700 (PDT) From: Almus Reply-To: Almus To: Brett Glass Cc: Ceren Ercen , chat@FreeBSD.ORG Subject: Re: bondage bsd daemon image In-Reply-To: <4.3.2.7.2.20001025092326.046f5ed0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The origonal "FREE BSD" with the space on the yellow background was an obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it was a shirt made for defcon) as that is out of date, I am considering dropping back to the "FreeBSD" probably in white on a black background.. what does everyone think? "If only I could get myself unchained from X Windows...." I think that quote is great.. and will add some of the humor back in, as the origonal joke the shirt was designed around is out of date now.. again.. what does everyonr think? I will make whichever shirt people would be more likely to buy.. (I have several of the defcon version which I am no longer selling, so I am making these for you, not me..) -Almus On Wed, 25 Oct 2000, Brett Glass wrote: > At 04:02 PM 10/24/2000, Ceren Ercen wrote: > > >http://www.satindeath.net/boundchuck.jpg > > > >He's removing the mention of DefCon from the bottom of the shirt. And if > >anyone can come up with a better slogan than "The only way to lock up this > >OS", he's open to suggestions. > > How about: > > > "If only I could get myself unchained from X Windows...." > > > In any case, he should remove the space between "FREE" and "BSD", or > (better) use the canonical mixed-case spelling ("FreeBSD"). > > --Brett > > -- It is my Firm Belief that it's a mistake to hold Firm Beliefs! <-Goth.Code98-> almus@dis.org www.dis.org/almus uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT -- Send private encrypted e-mail - Freedom 1.1 www.zks.net/clickthrough/click.asp?partner_id=111 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 19: 9:57 2000 Delivered-To: freebsd-chat@freebsd.org Received: from krell.webweaver.net (unknown [206.24.105.170]) by hub.freebsd.org (Postfix) with ESMTP id A211037B479 for ; Wed, 25 Oct 2000 19:09:54 -0700 (PDT) Received: from xwin.nmhtech.com (xwin.nmhtech.com [208.138.46.10]) by krell.webweaver.net (Postfix) with ESMTP id B597920F04; Wed, 25 Oct 2000 18:57:28 -0700 (PDT) Content-Length: 2718 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: Date: Wed, 25 Oct 2000 19:09:54 -0700 (PDT) From: "Nicole Harrington." To: Almus Subject: Re: bondage bsd daemon image Cc: chat@FreeBSD.ORG, Ceren Ercen , Brett Glass Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Oct-00 Almus wrote: > The origonal "FREE BSD" with the space on the yellow background was an > obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it > was a shirt made for defcon) as that is out of date, I am considering > dropping back to the "FreeBSD" probably in white on a black background.. > what does everyone think? > "If only I could get myself unchained from X Windows...." > I think that quote is great.. and will add some of the humor back in, as > the origonal joke the shirt was designed around is out of date now.. > again.. what does everyonr think? I will make whichever shirt people would > be more likely to buy.. > (I have several of the defcon version which I am no longer selling, so I > am making these for you, not me..) > > -Almus I really like the cover from the Japan magazine shown on Kirk's site of BSD Images. It has a picture of beastie behind bars with FreeBSD printed underneath. I would love to see that as a shirt as well. Nicole > > On Wed, 25 Oct 2000, Brett Glass wrote: > >> At 04:02 PM 10/24/2000, Ceren Ercen wrote: >> >> >http://www.satindeath.net/boundchuck.jpg >> > >> >He's removing the mention of DefCon from the bottom of the shirt. And if >> >anyone can come up with a better slogan than "The only way to lock up this >> >OS", he's open to suggestions. >> >> How about: >> >> >> "If only I could get myself unchained from X Windows...." >> >> >> In any case, he should remove the space between "FREE" and "BSD", or >> (better) use the canonical mixed-case spelling ("FreeBSD"). >> >> --Brett >> >> > > -- > It is my Firm Belief that it's a mistake > to hold Firm Beliefs! > <-Goth.Code98-> almus@dis.org www.dis.org/almus > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT > -- > > Send private encrypted e-mail - Freedom 1.1 > www.zks.net/clickthrough/click.asp?partner_id=111 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ nicole@deviantimages.com // \\ http://www.deviantimages.com/ ---------------------------(((---(((----------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- Strong enough for a man - But made for a Woman -- -- "I drank WHAT ?!" - Socrates -- Hmm You seem better - "been giving myself shock treatments" Up the Voltage! ----------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 23:11: 9 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id EA01737B479 for ; Wed, 25 Oct 2000 23:11:05 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id XAA04501; Wed, 25 Oct 2000 23:07:55 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAARYaGQi; Wed Oct 25 23:07:48 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id XAA11949; Wed, 25 Oct 2000 23:10:52 -0700 (MST) From: Terry Lambert Message-Id: <200010260610.XAA11949@usr08.primenet.com> Subject: Re: kqueue microbenchmark results To: bright@wintelcom.net (Alfred Perlstein) Date: Thu, 26 Oct 2000 06:10:52 +0000 (GMT) Cc: davids@webmaster.com (David Schwartz), jlemon@flugsvamp.com (Jonathan Lemon), chat@FreeBSD.ORG, linux-kernel@vger.kernel.org In-Reply-To: <20001025161837.D28123@fw.wintelcom.net> from "Alfred Perlstein" at Oct 25, 2000 04:18:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ ... blocking read after signalling that data is available ... ] > Yes, and as you mentioned, it was _bugs_ in the operating system > that did this. I think it's reasonable for the OS to discard, for example, connection requests which are not serviced in a reasonable time window. Likewise, it's reasonable to consider some protocol that would allow the sender to repudiate a packet that it decided that it didn't want to send; this would, in fact, be extremely useful in multicast protocols that signalled all available servers with a request, and then repudiated the request after receiving a response, on the theory that the server was too loaded, or the link to congested, or the programmer of the repudiated servers was such a bad coder that the server was too lazy to get off its butt and answer the request in a reasonable amount of time. A protocol based on this second approach would actually be able to solve "the gnutella congestion problem" (quoted, as I believe it's simply a case of the universe and the laws of physics voting against gnutella as being a dumb idea, since it's just a repeat of the original NetWare and LANMan scaling problems). The real problem is that the interface is making a potentially incorrect assumption about the underlying implementation, and that means that it won't be portable to systems whose underlying implementations don't satify the (undocumented and unwarranted) assumption. People whine about WSOCK32 being "gratuitously different" with regard to resource tracking and implying a shutdown on a socket close or an application exit, but they forget that that all came about because the original interface, and the programmers who used it, assumed a kernel space implementation, and that the kernel would resource track sockets, as if they were file descriptors. I think your Sun example: > POLLIN Data other than high priority data may be read > without blocking. For STREAMS, this flag is set in > revents even if the message is of zero length. Implies that a recv or recvfrom is required, and use of a read after a POLLIN, which can't retrieve high priority data from a socket, may result in the process blocking. Well, "duh!", the read is on the normal data channel, and the POLLIN corresponds to the high priority channel ...what did you expect, when you called the wrong system call on a socket? > I see a trend here, let's try Linux: Linux also thought it was OK to modify the contents of the timeval structure before returning it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Wed Oct 25 23:17:37 2000 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (unknown [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 5B48637B479 for ; Wed, 25 Oct 2000 23:17:31 -0700 (PDT) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 25 Oct 2000 23:17:00 -0700 From: "David Schwartz" To: "Alfred Perlstein" Cc: "Jonathan Lemon" , , Subject: RE: kqueue microbenchmark results Date: Wed, 25 Oct 2000 23:17:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001025161837.D28123@fw.wintelcom.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > * David Schwartz [001025 15:35] wrote: > > > > If a programmer does not ever wish to block under any > circumstances, it's > > his obligation to communicate this desire to the > implementation. Otherwise, > > the implementation can block if it doesn't have data or an > error available > > at the instant 'read' is called, regardless of what it may have known or > > done in the past. It's also just generally good programming > practice. There > > was a time when many operating systems had bugs that caused > 'select loop' > > type applications to hang if they didn't set all their descriptors > > non-blocking. > > Yes, and as you mentioned, it was _bugs_ in the operating system > that did this. Right. I can't imagine a way in which this could happen for TCP without a bug. For other protocols, it's not so far fetched. For UDP, which is defined as lossy, I could imagine an implementation that changed its mind about accepting a packet due to memory demands. > I don't think it's wise to continue speculating on this issue unless > you can point to a specific document that says that it's OK for > this type of behavior to happen. SuS2 says that 'read' behaves like 'recv' with no flags for a socket. SuS2 says that for a socket, "If no messages are available at the socket and O_NONBLOCK is not set on the socket's file descriptor, recv() blocks until a message arrives." > Let's take a look at the FreeBSD manpage for poll: > > POLLIN Data other than high priority data may be read without > blocking. At the time you return from poll. This says nothing about any later time. [snip] > #define POLLIN 0x0001 /* There is data to read */ > > This seems to imply that it is one hell of a bug to block, returning > an error would be acceptable, but surely not blocking. This brief comment is not meant to be thorough. In fact, it says nothing about error conditions and implies that it's wrong to return POLLIN for an error. > I know manpages are a poor source for references but you're the one > putting up a big fight for blocking behavior from poll, perhaps you > can point out a standard that contradicts the manpages? When you code to a standard, your code must not fail under any conditions permitted by the standard. Failing to set your file descriptors non-blocking when you never want to block depends upon behavior not guaranteed. Unfortunately, none of the standards provides sufficiently clear statements about this behavior. In fact, I can't even find any standard that says it's correct to signal POLLIN when there's an error. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 0: 4:49 2000 Delivered-To: freebsd-chat@freebsd.org Received: from kizmiaz.dis.org (kizmiaz.dis.org [216.240.45.60]) by hub.freebsd.org (Postfix) with ESMTP id 8362637B479 for ; Thu, 26 Oct 2000 00:04:45 -0700 (PDT) Received: from localhost (almus@localhost) by kizmiaz.dis.org (8.9.3/8.9.3) with SMTP id AAA16075; Thu, 26 Oct 2000 00:04:39 -0700 (PDT) Date: Thu, 26 Oct 2000 00:04:38 -0700 (PDT) From: Almus To: "Nicole Harrington." Cc: chat@FreeBSD.ORG, Ceren Ercen , Brett Glass Subject: Re: bondage bsd daemon image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I havent seen this one.. anyone have a direct link? -Almus On Wed, 25 Oct 2000, Nicole Harrington. wrote: > > On 26-Oct-00 Almus wrote: > > The origonal "FREE BSD" with the space on the yellow background was an > > obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it > > was a shirt made for defcon) as that is out of date, I am considering > > dropping back to the "FreeBSD" probably in white on a black background.. > > what does everyone think? > > "If only I could get myself unchained from X Windows...." > > I think that quote is great.. and will add some of the humor back in, as > > the origonal joke the shirt was designed around is out of date now.. > > again.. what does everyonr think? I will make whichever shirt people would > > be more likely to buy.. > > (I have several of the defcon version which I am no longer selling, so I > > am making these for you, not me..) > > > > -Almus > > I really like the cover from the Japan magazine shown on Kirk's site of BSD > Images. It has a picture of beastie behind bars with FreeBSD printed > underneath. > > I would love to see that as a shirt as well. > > Nicole > > > > > > > On Wed, 25 Oct 2000, Brett Glass wrote: > > > >> At 04:02 PM 10/24/2000, Ceren Ercen wrote: > >> > >> >http://www.satindeath.net/boundchuck.jpg > >> > > >> >He's removing the mention of DefCon from the bottom of the shirt. And if > >> >anyone can come up with a better slogan than "The only way to lock up this > >> >OS", he's open to suggestions. > >> > >> How about: > >> > >> > >> "If only I could get myself unchained from X Windows...." > >> > >> > >> In any case, he should remove the space between "FREE" and "BSD", or > >> (better) use the canonical mixed-case spelling ("FreeBSD"). > >> > >> --Brett > >> > >> > > > > -- > > It is my Firm Belief that it's a mistake > > to hold Firm Beliefs! > > <-Goth.Code98-> almus@dis.org www.dis.org/almus > > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 > > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT > > -- > > > > Send private encrypted e-mail - Freedom 1.1 > > www.zks.net/clickthrough/click.asp?partner_id=111 > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-chat" in the body of the message > > nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ > webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ > nicole@deviantimages.com // \\ http://www.deviantimages.com/ > > ---------------------------(((---(((----------------------------------------- > > -- Powered by Coka-Cola and FreeBSD -- > -- Strong enough for a man - But made for a Woman -- > -- "I drank WHAT ?!" - Socrates -- > Hmm You seem better - "been giving myself shock treatments" Up the Voltage! > ----------------------------------------------------------------------------- > > -- It is my Firm Belief that it's a mistake to hold Firm Beliefs! <-Goth.Code98-> almus@dis.org www.dis.org/almus uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT -- Send private encrypted e-mail - Freedom 1.1 www.zks.net/clickthrough/click.asp?partner_id=111 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 2:13:27 2000 Delivered-To: freebsd-chat@freebsd.org Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by hub.freebsd.org (Postfix) with ESMTP id B9A0537B479 for ; Thu, 26 Oct 2000 02:13:25 -0700 (PDT) Received: from fedex.cisco.com (fedex.cisco.com [171.69.18.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id CAA13221; Thu, 26 Oct 2000 02:13:18 -0700 (PDT) Received: from cisco.com ([10.19.99.146]) by fedex.cisco.com (Mirapoint) with ESMTP id AGV38225 (AUTH gid); Thu, 26 Oct 2000 02:13:18 -0700 (PDT) Message-ID: <39F7F66C.55B158@cisco.com> Date: Thu, 26 Oct 2000 02:16:28 -0700 From: Gideon Glass X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: Simon Kirby , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> <20001025165626.B87091@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > > Also, consider the following scenario for the proposed get_event(): > > 1. packet arrives, queues an event. > 2. user retrieves event. > 3. second packet arrives, queues event again. > 4. user reads() all data. > > Now, next time around the loop, we get a notification for an event > when there is no data to read. The application now must be prepared > to handle this case (meaning no blocking read() calls can be used). > > Also, what happens if the user closes the socket after step 4 above? Depends on the implementation. If the item in the queue is the struct file (or whatever an fd indexes to), then the implementation can only queue the fd once. This also avoids the problem with closing sockets - close() would naturally do a list_del() or whatever on the struct file. At least I think it could be implemented this way... gid > > The user now receives a notification for a fd which no longer exists, > or possibly has been reused for another connection. This may or may > not make a difference to the application, but it must be prepared to > handle it anyway. I believe that Zack Brown ran into this problem with > one of the webservers he was writing. > > > > You can find my paper at http://people.freebsd.org/~jlemon > > > > I'll go and read it now. :) > > The paper talks about some of the issues we have been discussing, as > well as the design rationale behind kqueue. I'd be happy to answer > any questions about the paper. > -- > Jonathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 9:52:39 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0C3B737B4C5 for ; Thu, 26 Oct 2000 09:52:36 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9QGovP23273; Thu, 26 Oct 2000 11:50:57 -0500 (CDT) (envelope-from jlemon) Date: Thu, 26 Oct 2000 11:50:57 -0500 From: Jonathan Lemon To: Gideon Glass Cc: Jonathan Lemon , Simon Kirby , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001026115057.A22681@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> <20001025165626.B87091@prism.flugsvamp.com> <39F7F66C.55B158@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <39F7F66C.55B158@cisco.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Oct 26, 2000 at 02:16:28AM -0700, Gideon Glass wrote: > Jonathan Lemon wrote: > > > > Also, consider the following scenario for the proposed get_event(): > > > > 1. packet arrives, queues an event. > > 2. user retrieves event. > > 3. second packet arrives, queues event again. > > 4. user reads() all data. > > > > Now, next time around the loop, we get a notification for an event > > when there is no data to read. The application now must be prepared > > to handle this case (meaning no blocking read() calls can be used). > > > > Also, what happens if the user closes the socket after step 4 above? > > Depends on the implementation. If the item in the queue is the > struct file (or whatever an fd indexes to), then the implementation > can only queue the fd once. This also avoids the problem with > closing sockets - close() would naturally do a list_del() or whatever > on the struct file. > > At least I think it could be implemented this way... kqueue currently does this; a close() on an fd will remove any pending events from the queues that they are on which correspond to that fd. I was trying to point out that it isn't as simple as it would seem at first glance, as you have to consider an issues like this. Also, if the implementation allows multiple event types per fd, (leading to multiple queued events per fd) there no longer is a 1:1 mapping to something like 'struct file', and performing a list walk doesn't scale very well. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 10:39:33 2000 Delivered-To: freebsd-chat@freebsd.org Received: from krell.webweaver.net (unknown [206.24.105.170]) by hub.freebsd.org (Postfix) with ESMTP id B3CBA37B4C5 for ; Thu, 26 Oct 2000 10:39:29 -0700 (PDT) Received: from xwin.nmhtech.com (xwin.nmhtech.com [208.138.46.10]) by krell.webweaver.net (Postfix) with ESMTP id 4DAAE20F04; Thu, 26 Oct 2000 10:26:59 -0700 (PDT) Content-Length: 4345 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: Date: Thu, 26 Oct 2000 10:39:29 -0700 (PDT) From: "Nicole Harrington." To: Almus Subject: Re: bondage bsd daemon image Cc: Brett Glass , Ceren Ercen , chat@FreeBSD.ORG Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26-Oct-00 Almus wrote: > I havent seen this one.. anyone have a direct link? > > -Almus Ahha... It wasn't on kirk's site... Here's a link http://www.freebsd.org/gifs/coverb.jpg Nicole > > On Wed, 25 Oct 2000, Nicole Harrington. wrote: > >> >> On 26-Oct-00 Almus wrote: >> > The origonal "FREE BSD" with the space on the yellow background was an >> > obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it >> > was a shirt made for defcon) as that is out of date, I am considering >> > dropping back to the "FreeBSD" probably in white on a black background.. >> > what does everyone think? >> > "If only I could get myself unchained from X Windows...." >> > I think that quote is great.. and will add some of the humor back in, as >> > the origonal joke the shirt was designed around is out of date now.. >> > again.. what does everyonr think? I will make whichever shirt people would >> > be more likely to buy.. >> > (I have several of the defcon version which I am no longer selling, so I >> > am making these for you, not me..) >> > >> > -Almus >> >> I really like the cover from the Japan magazine shown on Kirk's site of BSD >> Images. It has a picture of beastie behind bars with FreeBSD printed >> underneath. >> >> I would love to see that as a shirt as well. >> >> Nicole >> >> >> >> > >> > On Wed, 25 Oct 2000, Brett Glass wrote: >> > >> >> At 04:02 PM 10/24/2000, Ceren Ercen wrote: >> >> >> >> >http://www.satindeath.net/boundchuck.jpg >> >> > >> >> >He's removing the mention of DefCon from the bottom of the shirt. And if >> >> >anyone can come up with a better slogan than "The only way to lock up >> >> >this >> >> >OS", he's open to suggestions. >> >> >> >> How about: >> >> >> >> >> >> "If only I could get myself unchained from X Windows...." >> >> >> >> >> >> In any case, he should remove the space between "FREE" and "BSD", or >> >> (better) use the canonical mixed-case spelling ("FreeBSD"). >> >> >> >> --Brett >> >> >> >> >> > >> > -- >> > It is my Firm Belief that it's a mistake >> > to hold Firm Beliefs! >> > <-Goth.Code98-> almus@dis.org www.dis.org/almus >> > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 >> > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT >> > -- >> > >> > Send private encrypted e-mail - Freedom 1.1 >> > www.zks.net/clickthrough/click.asp?partner_id=111 >> > >> > >> > >> > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > with "unsubscribe freebsd-chat" in the body of the message >> >> nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ >> webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ >> nicole@deviantimages.com // \\ http://www.deviantimages.com/ >> >> ---------------------------(((---(((----------------------------------------- >> >> -- Powered by Coka-Cola and FreeBSD -- >> -- Strong enough for a man - But made for a Woman -- >> -- "I drank WHAT ?!" - Socrates -- >> Hmm You seem better - "been giving myself shock treatments" Up the Voltage! >> ----------------------------------------------------------------------------- >> >> > > -- > It is my Firm Belief that it's a mistake > to hold Firm Beliefs! > <-Goth.Code98-> almus@dis.org www.dis.org/almus > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT > -- > > Send private encrypted e-mail - Freedom 1.1 > www.zks.net/clickthrough/click.asp?partner_id=111 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ nicole@deviantimages.com // \\ http://www.deviantimages.com/ ---------------------------(((---(((----------------------------------------- -- Powered by Coka-Cola and FreeBSD -- -- Strong enough for a man - But made for a Woman -- -- "I drank WHAT ?!" - Socrates -- Hmm You seem better - "been giving myself shock treatments" Up the Voltage! ----------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 10:58:10 2000 Delivered-To: freebsd-chat@freebsd.org Received: from imo-r06.mail.aol.com (imo-r06.mx.aol.com [152.163.225.6]) by hub.freebsd.org (Postfix) with ESMTP id 327B437B479 for ; Thu, 26 Oct 2000 10:58:08 -0700 (PDT) Received: from JFin1959@aol.com by imo-r06.mx.aol.com (mail_out_v28.32.) id n.aa.c4c49f0 (4011) for ; Thu, 26 Oct 2000 13:57:53 -0400 (EDT) From: JFin1959@aol.com Message-ID: Date: Thu, 26 Oct 2000 13:57:52 EDT Subject: Free BSD 4-Color Magazine To: freebsd-chat@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Windows AOL sub 123 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Free BSD user \ subscriber, My name is John Finlay, and I am a magazine publisher, hard copy, not online. I publish 4-color magazines such as Concierge magazine and New Senior Living. These magazines are printed on high quality, glossy paper with sophisticated graphics. Through my association with a BSD user in Houston, I am exploring the idea of publishing a Free BSD magazine. This magazine would contain pertinent articles by the leaders in the BSD industry, and include tech-type advertising to support the publication. My inquiry to you is this, would you be willing to pay for a monthly or quarterly magazine dealing with BSD issues? I anticipate a subscription rate of $5-8 per issue, which will include mailing. My associate has assured me that we will be able to put the magazine on-line as well as publish it in hard copy format. I am presently publishing New Senior Living in Houston, Central \ Southeast Texas, Dallas-Ft. Worth, and Oklahoma. I am presently publishing Concierge in Houston and Dallas. These are totally unrelated magazines, but are very expensive, nice publications that show I am serious about the publishing business. Any comments or suggestions you have on this topic are greatly appreciated. My address is: jfin1959@aol.com or JAM Publications, Inc. 2620--B South Shepherd Drive Suite # 131 Houston, Texas 77098 Telephone: 713-942-7703-------713-942-0698------- National pager: 713-994-7690 I am in the process of contacting the Free BSD companies and authors to gauge interest in this project. Thank you very much for your time and interest. Sincerely, John Finlay JAM Publications, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 11: 9:22 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 59B1D37B479 for ; Thu, 26 Oct 2000 11:09:17 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id LAA24011; Thu, 26 Oct 2000 11:09:41 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAMuaWUU; Thu Oct 26 11:09:29 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA00925; Thu, 26 Oct 2000 11:08:57 -0700 (MST) From: Terry Lambert Message-Id: <200010261808.LAA00925@usr08.primenet.com> Subject: Re: kqueue microbenchmark results To: tlambert@primenet.com (Terry Lambert) Date: Thu, 26 Oct 2000 18:08:51 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), davids@webmaster.com (David Schwartz), jlemon@flugsvamp.com (Jonathan Lemon), chat@FreeBSD.ORG, linux-kernel@vger.kernel.org In-Reply-To: <200010260610.XAA11949@usr08.primenet.com> from "Terry Lambert" at Oct 26, 2000 06:10:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a long posting, with a humble beginning, but it has a point. I'm being complete so that no one is left in the dark, or in any doubt as to what that point is. That means rehashing some history. This posting is not really about select or Linux: it's about interfaces. Like cached state, interfaces can often be harmful. NB: I really should redirect this to FreeBSD, as well, since there are people in that camp who haven't learned the lesson, either, but I'll leave it in -chat, for now. --- [ ... kqueue discussion ... ] > Linux also thought it was OK to modify the contents of the > timeval structure before returning it. It's been pointed out that I should provide more context for this statement, before people look at me strangely and make circling motions with their index fingers around their ears (or whatever the international sign for "crazy" is these days). So I'll start with a brief history. The context is this: the select API was designed with the idea that one might wish to do non-I/O related background processing. Toward this end, one could have several ways of using the API: 1) The (struct timeval *) could be NULL. This means "block until a signal or until a condition on which you are selecting is true"; select is a BSD interface, and, until BSD 4.x and POSIX signals, the signal would actually call the handler and restart the select call, so in effect, this really meant "block until you longjmp out of a signal handler or until a condition on which you are selecting is true". 2) The (struct timeval *) could point to the address of a real timeval structure (i.e. not be NULL); in that case, the result depended on the contents: a) If the timeval struct was zero valued, it meant that the select should poll for one of the conditions being selected for in the descriptor set, and return a 0 if no conditions were true. The contents of the bitmaps and timeval struct were left alone. b) If the timeval struct was not zero valued, it meant that the select should wait until the time specified had expired since the system call was first started, or one of the conditions being selected for was true. If the timeout expired, then a 0 would be returned, but if one or more of the conditions were true, the number of descriptors on which true conditions existed would be returned. Wedging so much into a single interface was fraught with peril: it was undefined as to what would happen if the timeval specified an interval of 5 seconds, yet there was a persistently rescheduled alarm every 2 seconds, resulting in a signal handler call that did _not_ longjmp... would the timer expire after 5 seconds, or would the timer be considered to have been restarted along with the call? Implementations that went both ways existed. Mostly, programmers used longjmp in signal handlers, and it wasn't a portability issue. More perilous, the question of what to do with a partially satisfied request that was interrupted with a timer or signal handler and longjump (later, siginterrupt(2), and later POSIX non-restart default behaviour). This meant that the bitmap of select events might have been modified already, after the wakeup, but before the process was rescheduled to run. Finally, the select manual page specifically reserved the right to modify the contents of the timeval struct; this was presumably so that you could either do accurate timekeeping by maintaining a running tally using the timeval deficit (a lot of math, that), or, more likely, to deal with the system call restart, and ensure that signals would not prevent the select from ever exiting in the case of system call restart. So this was the select API definition. --- Being pragmatists, programmers programmed to the behaviour of the API in actual implementations, rather than to the strict "letter of the law" laid down by the man page. This meant that select was called in loop control constructs, and that the bitmaps were reinitialized each time through the loop. It also meant that the timeval struct was not reinitialized, since that was more work, and no known implementations would modify it. Pre-POSIX signals, signal handlers were handled on a signal stack, as a result of a kernel trampoline outcall, and that meant that a restarting system call would not impact the countdown. --- Linux came along, and implemented the letter of the law; the machines were no sufficiently fast, and the math sufficiently cheap, that it was now possible to usefully accurate timekeeping using the inverted math required of keeping a running tally using the timeval deficit. So they implemented it: it was more useful than the historical behaviour on most platforms. And every program which used non-zero valued timeval struct contents, and assumed that they would not be modified, broke. --- And here we see the problem with defining interfaces instead of defining protocols. A protocol is unambiguous with regard to implementation details. But an API, unless a lot of work takes place to make it sufficiently abstract, and a lot more work takes place to define exactly what will happen in all allowed conditions, and to preclude the possibility of undefined behaviour, simply can not hide implementation details. If what people are trying to do here is define a cross-platform system interface (and if they succeed, it will be the first one forced on mainstream UNIX by the Open Source community), then it means that careful design which eliminates ambiguity is the single most important consideration. There can be no undefined behaviour, like that of select's timeval struct updating, or the equally ambiguous, but less problematic, bitmap content partial update -- which could bite people on a new platform, but so far has not. --- I have seen the BSD kqueue interface called "overengineered"; but people apparently don't realize that it is not so much that it has been thought out to that level of detail beforehand, as it is that it is on its third revision. It wasn't really overengineered to where it is today: it has matured to where it is today. Just as poll (however much I disdain it for select, in favor of select's more universal platform portability) is a more mature interface than select, and resolves problems in the select design. Poll is not an overengineered interface, it is a more mature version of the select interface. --- FWIW: except for platform-specific applications, which I've tried very hard to avoid writing since the early 1980's or so, I will probably be very conservative in my adoption of a kqueue interface, whatever it ends up looking like, just as I've been conservative in my adoption of poll (and, untill 1989, my adoption of select, since there are other ways to solve the multiple input stream problem, without needing a select, poll, or kqueue, and which work all the way back to V7 UNIX). Unless there's a problem that can not be solved in any other way, such as performance or footprint, I'll stick to tools that are cross-platform. On general principles, it'd be a good idea if BSD and Linux ended up with the same unambiguous interface. The wider an interface is adopted, the quicker you will see people who can't afford to be nailed to the cross of a single platform willing to adopt it in their code. Ambiguity of any kind will hinder that adoption, and would certainly prevent adoption by mainstream UNIX: if you have to code it differently on different platforms, then you might as well code it differently on their platform, too. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 11:19:12 2000 Delivered-To: freebsd-chat@freebsd.org Received: from phoenix.welearn.com.au (unknown [139.130.44.81]) by hub.freebsd.org (Postfix) with ESMTP id 5B0F437B479 for ; Thu, 26 Oct 2000 11:19:07 -0700 (PDT) Received: (from sue@localhost) by phoenix.welearn.com.au (8.9.3/8.9.3) id FAA87173 for chat@freebsd.org; Fri, 27 Oct 2000 05:24:36 +1000 (EST) (envelope-from sue) Date: Fri, 27 Oct 2000 05:24:32 +1000 From: Sue Blake To: chat@freebsd.org Subject: For women only :-) Message-ID: <20001027052430.I2537@welearn.com.au> Mail-Followup-To: chat@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, now that everyone's here... :-) I'm planning to throw together a web page about women in FreeBSD. At this stage the idea is to have a couple of sentences about each of a few women, what they do with FreeBSD and maybe a URL link, so that new women can see some evidence that we're already taken seriously even though we're quiet about it. If you're a woman and would be happy to be represented, and/or can offer feedback or improvements on the idea, please contact me off list. Whether you're male or female, if you know a woman who uses FreeBSD and who could be interested, please forward this to her. TIA. -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 12:51:53 2000 Delivered-To: freebsd-chat@freebsd.org Received: from exchange.nils.lib.il.us (mailsrv.nils.lib.il.us [206.190.22.38]) by hub.freebsd.org (Postfix) with ESMTP id 3AB2637B479 for ; Thu, 26 Oct 2000 12:51:50 -0700 (PDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id <4Y3DQKY7>; Thu, 26 Oct 2000 14:52:13 -0500 Message-ID: <3073B3378589D411B21600508BAF32AA18A23B@EXCHANGE> From: Nathan Williams To: 'Almus' Cc: chat@FreeBSD.ORG Subject: RE: bondage bsd daemon image Date: Thu, 26 Oct 2000 14:52:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that ("FREE BSD") has a lot of historical value for geeks. I would wear that shirt at least once a week just to give me a laugh. I'd definitely buy one. Nathan Williams nathanw@nils.lib.il.us -----Original Message----- From: Almus [mailto:almus@kizmiaz.dis.org] Sent: Wednesday, October 25, 2000 7:05 PM To: Brett Glass Cc: Ceren Ercen; chat@FreeBSD.ORG Subject: Re: bondage bsd daemon image The origonal "FREE BSD" with the space on the yellow background was an obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it was a shirt made for defcon) as that is out of date, I am considering dropping back to the "FreeBSD" probably in white on a black background.. what does everyone think? "If only I could get myself unchained from X Windows...." I think that quote is great.. and will add some of the humor back in, as the origonal joke the shirt was designed around is out of date now.. again.. what does everyonr think? I will make whichever shirt people would be more likely to buy.. (I have several of the defcon version which I am no longer selling, so I am making these for you, not me..) -Almus On Wed, 25 Oct 2000, Brett Glass wrote: > At 04:02 PM 10/24/2000, Ceren Ercen wrote: > > >http://www.satindeath.net/boundchuck.jpg > > > >He's removing the mention of DefCon from the bottom of the shirt. And if > >anyone can come up with a better slogan than "The only way to lock up this > >OS", he's open to suggestions. > > How about: > > > "If only I could get myself unchained from X Windows...." > > > In any case, he should remove the space between "FREE" and "BSD", or > (better) use the canonical mixed-case spelling ("FreeBSD"). > > --Brett > > -- It is my Firm Belief that it's a mistake to hold Firm Beliefs! <-Goth.Code98-> almus@dis.org www.dis.org/almus uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT -- Send private encrypted e-mail - Freedom 1.1 www.zks.net/clickthrough/click.asp?partner_id=111 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 15:31: 3 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2F5C537B479 for ; Thu, 26 Oct 2000 15:31:02 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9QMV1L05724 for chat@freebsd.org; Thu, 26 Oct 2000 15:31:01 -0700 (PDT) Date: Thu, 26 Oct 2000 15:31:01 -0700 From: Alfred Perlstein To: chat@freebsd.org Subject: through the looking glass Message-ID: <20001026153101.O28123@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Of course this is 'ok' because it's chat right? http://theonion.com/onion3638/forwarded_lawyer_jokes.html -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 17:50:29 2000 Delivered-To: freebsd-chat@freebsd.org Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by hub.freebsd.org (Postfix) with ESMTP id 329ED37B479 for ; Thu, 26 Oct 2000 17:50:27 -0700 (PDT) Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13oxjH-00041y-00; Fri, 27 Oct 2000 01:50:43 +0100 Subject: Re: kqueue microbenchmark results To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Fri, 27 Oct 2000 01:50:40 +0100 (BST) Cc: gid@cisco.com (Gideon Glass), jlemon@flugsvamp.com (Jonathan Lemon), sim@stormix.com (Simon Kirby), dank@alumni.caltech.edu (Dan Kegel), chat@freebsd.org, linux-kernel@vger.kernel.org In-Reply-To: <20001026115057.A22681@prism.flugsvamp.com> from "Jonathan Lemon" at Oct 26, 2000 11:50:57 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > kqueue currently does this; a close() on an fd will remove any pending > events from the queues that they are on which correspond to that fd. This seems an odd thing to do. Surely what you need to do is to post a 'close completed' event to the queue. This also makes more sense when you have a threaded app and another thread may well currently be in say a read at the time it is closed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 18: 3:14 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4F5C437B479 for ; Thu, 26 Oct 2000 18:03:12 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9R12vw09939; Thu, 26 Oct 2000 18:02:57 -0700 (PDT) Date: Thu, 26 Oct 2000 18:02:57 -0700 From: Alfred Perlstein To: Alan Cox Cc: Jonathan Lemon , Gideon Glass , Simon Kirby , Dan Kegel , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001026180256.R28123@fw.wintelcom.net> References: <20001026115057.A22681@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Oct 27, 2000 at 01:50:40AM +0100 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alan Cox [001026 17:50] wrote: > > kqueue currently does this; a close() on an fd will remove any pending > > events from the queues that they are on which correspond to that fd. > > This seems an odd thing to do. Surely what you need to do is to post a > 'close completed' event to the queue. This also makes more sense when you > have a threaded app and another thread may well currently be in say a read > at the time it is closed Kqueue's flexibility could allow this to be implemented, all you would need to do is make a new filter trigger. You might need a _bit_ of hackery to make sure those aren't removed, or one could just add the event after clearing all pending events. Adding a filter to be informed when a specific fd is closed is certainly an option, it doesn't make very much sense because that fd could then be reused quickly by something else... but anyhow: The point of this interface is to ask kqueue to report only on the things you are interested in, not to generate superfluous that you wouldn't care about. You could make such a flag if Linux adopted this interface and I'm sure we'd be forced to adopt it, but if you make kqueue generate info an application won't care about I don't think that would be taken back. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 18:12:26 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id B6BDA37B479 for ; Thu, 26 Oct 2000 18:12:24 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9R1AgS39078; Thu, 26 Oct 2000 20:10:42 -0500 (CDT) (envelope-from jlemon) Date: Thu, 26 Oct 2000 20:10:42 -0500 From: Jonathan Lemon To: Alan Cox Cc: Jonathan Lemon , Gideon Glass , Simon Kirby , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001026201042.A38500@prism.flugsvamp.com> References: <20001026115057.A22681@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Oct 27, 2000 at 01:50:40AM +0100, Alan Cox wrote: > > kqueue currently does this; a close() on an fd will remove any pending > > events from the queues that they are on which correspond to that fd. > > This seems an odd thing to do. Surely what you need to do is to post a > 'close completed' event to the queue. This also makes more sense when you > have a threaded app and another thread may well currently be in say a read > at the time it is closed Actually, it makes sense when you think about it. The `fd' is actually a capability that the application uses to refer to the open file in the kernel. If the app does a close() on the fd, it destroys this naming. The application then has no capability left which refers to the formerly open socket, and conversly, the kernel has no capability (name) to notify the application of a close event. What can I say, "the fd formerly known as X" is now gone? It would be incorrect to say that "fd X was closed", since X no longer refers to anything, and the application may have reused that fd for another file. As for the multi-thread case, this would be a bug; if one thread closes the descriptor, the other thread is going to get an EBADF when it goes to perform the read. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 18:33: 1 2000 Delivered-To: freebsd-chat@freebsd.org Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B80E37B479 for ; Thu, 26 Oct 2000 18:32:59 -0700 (PDT) Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13oyOE-00044z-00; Fri, 27 Oct 2000 02:33:02 +0100 Subject: Re: kqueue microbenchmark results To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Fri, 27 Oct 2000 02:32:59 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), jlemon@flugsvamp.com (Jonathan Lemon), gid@cisco.com (Gideon Glass), sim@stormix.com (Simon Kirby), dank@alumni.caltech.edu (Dan Kegel), chat@freebsd.org, linux-kernel@vger.kernel.org In-Reply-To: <20001026201042.A38500@prism.flugsvamp.com> from "Jonathan Lemon" at Oct 26, 2000 08:10:42 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > the application of a close event. What can I say, "the fd formerly known > as X" is now gone? It would be incorrect to say that "fd X was closed", > since X no longer refers to anything, and the application may have reused > that fd for another file. Which is precisely why you need to know where in the chain of events this happened. Otherwise if I see 'read on fd 5' 'read on fd 5' How do I know which read is for which fd in the multithreaded case > As for the multi-thread case, this would be a bug; if one thread closes > the descriptor, the other thread is going to get an EBADF when it goes > to perform the read. Another thread may already have reused the fd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 18:46:57 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C10CA37B479 for ; Thu, 26 Oct 2000 18:46:55 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9R1knD11185; Thu, 26 Oct 2000 18:46:49 -0700 (PDT) Date: Thu, 26 Oct 2000 18:46:49 -0700 From: Alfred Perlstein To: Alan Cox Cc: Jonathan Lemon , Gideon Glass , Simon Kirby , Dan Kegel , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001026184649.U28123@fw.wintelcom.net> References: <20001026201042.A38500@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Oct 27, 2000 at 02:32:59AM +0100 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alan Cox [001026 18:33] wrote: > > the application of a close event. What can I say, "the fd formerly known > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > since X no longer refers to anything, and the application may have reused > > that fd for another file. > > Which is precisely why you need to know where in the chain of events this > happened. Otherwise if I see > > 'read on fd 5' > 'read on fd 5' > > How do I know which read is for which fd in the multithreaded case No you don't, you don't see anything with the current code unless fd 5 is still around, what you're presenting to Jonathan is a application threading problem, not something that need to be resolved by the OS. > > As for the multi-thread case, this would be a bug; if one thread closes > > the descriptor, the other thread is going to get an EBADF when it goes > > to perform the read. > > Another thread may already have reused the fd This is another example of an application threading problem. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 21:28:39 2000 Delivered-To: freebsd-chat@freebsd.org Received: from whizkidtech.net (r46.bfm.org [216.127.220.142]) by hub.freebsd.org (Postfix) with ESMTP id DEEEC37B479 for ; Thu, 26 Oct 2000 21:28:35 -0700 (PDT) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id XAA00255 for chat@freebsd.org; Thu, 26 Oct 2000 23:27:28 -0500 (CDT) (envelope-from adam) Date: Thu, 26 Oct 2000 23:27:27 -0500 From: "G. Adam Stanislav" To: chat@freebsd.org Subject: What the ??ck! Message-ID: <20001026232727.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmm, sheesh, gosh! So, I entered what I thought was http://www.freebsd.org/ in my browser, and here comes this weird page full of banners, plus a JavaScript pop-up window (gosh, I hate those!). And I'm wondering what the heck happened. Then I noticed I mistyped. The site was actually http://www.frebsd.org/ (just one 'e'). Looks to me someone is trying to cash in on FreeBSD's good name, and hoping others will mistype just as I did. Strangely enough, this someone is anonymous. Here's what whois has to say: --------------------------------------------------------------------------- Whois Server Version 1.3 Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: FREBSD.ORG Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: ORANGE.IDIRECTIONS.COM Name Server: GREEN.IDIRECTIONS.COM Updated Date: 02-oct-2000 >>> Last update of whois database: Thu, 26 Oct 2000 06:47:54 EDT <<< The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars. -------------------------------------------------------------------------- Now, isn't that special? Adam -- When two do the same, it's not the same -- Slovak proverb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 21:41:13 2000 Delivered-To: freebsd-chat@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9DD6637B479 for ; Thu, 26 Oct 2000 21:41:09 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9R4ew009227; Fri, 27 Oct 2000 14:10:58 +0930 (CST) (envelope-from grog) Date: Fri, 27 Oct 2000 14:10:58 +0930 From: Greg Lehey To: "G. Adam Stanislav" Cc: chat@FreeBSD.ORG Subject: Re: What the ??ck! Message-ID: <20001027141058.E51550@wantadilla.lemis.com> References: <20001026232727.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001026232727.A228@whizkidtech.net>; from adam@whizkidtech.net on Thu, Oct 26, 2000 at 11:27:27PM -0500 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 26 October 2000 at 23:27:27 -0500, G. Adam Stanislav wrote: > Hmmm, sheesh, gosh! > > So, I entered what I thought was http://www.freebsd.org/ in my browser, > and here comes this weird page full of banners, plus a JavaScript pop-up > window (gosh, I hate those!). > > And I'm wondering what the heck happened. Then I noticed I mistyped. The > site was actually http://www.frebsd.org/ (just one 'e'). > > Looks to me someone is trying to cash in on FreeBSD's good name, and > hoping others will mistype just as I did. Ugh. I suppose that's the price for fame. I wish there were some rules which required .orgs to be non-commercial. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 22:11:36 2000 Delivered-To: freebsd-chat@freebsd.org Received: from 123.211.6.64.reflexcom.com (123.211.6.64.reflexcom.com [64.6.211.123]) by hub.freebsd.org (Postfix) with ESMTP id BB7AA37B479 for ; Thu, 26 Oct 2000 22:11:33 -0700 (PDT) Received: (from anguiano@localhost) by 123.211.6.64.reflexcom.com (8.9.3/8.9.3) id WAA45172; Thu, 26 Oct 2000 22:10:50 -0700 (PDT) (envelope-from anguiano@123.211.6.64.reflexcom.com) X-Authentication-Warning: 123.211.6.64.reflexcom.com: anguiano set sender to anguiano@123.211.6.64.reflexcom.com using -f To: "G. Adam Stanislav" Cc: chat@FreeBSD.ORG Subject: Re: What the ??ck! References: <20001026232727.A228@whizkidtech.net> From: Ricardo Anguiano Reply-To: Ricardo Anguiano Date: 26 Oct 2000 22:10:48 -0700 In-Reply-To: "G. Adam Stanislav"'s message of "Thu, 26 Oct 2000 23:27:27 -0500" Message-ID: <86d7gmq36v.fsf@123.211.6.64.reflexcom.com> Lines: 57 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Courtesy geektools.com whois service. -Ricardo ------------------------------------------------------------ Server used for this query: [ whois.networksolutions.com ] Registrant: NAMEZERO.COM (FREBSD-DOM) 51 University Ave, Suite K LOS GATOS, CA 95030 US Domain Name: FREBSD.ORG Administrative Contact: NAMEZERO.COM (NC3029-ORG) admin@namezero.com NAMEZERO.COM 51 University Ave, Suite K LOS GATOS, CA 95030 US 4083950426 fax: 4083950436 Technical Contact, Zone Contact: Technical Coordinator (TC6611-ORG) tech@NAMEZERO.COM namezero.com, Inc. 51 University Ave, Suite K Los Gatos, CA 95030 US 408-395-0426 Fax- - 408-395-0436 Billing Contact: NAMEZERO.COM-WN-BCIA (NC3027-ORG) bills@NAMZERO.COM NAMEZERO.COM 262 East Main Street LOS GATOS, CA 95030 US 4083950426 Fax- - 4083950436 Record last updated on 02-Oct-2000. Record expires on 02-Oct-2001. Record created on 02-Oct-2000. Database last updated on 25-Oct-2000 21:12:39 EDT. Domain servers in listed order: GREEN.IDIRECTIONS.COM 216.34.13.231 ORANGE.IDIRECTIONS.COM 216.34.13.234 "G. Adam Stanislav" writes: > Strangely enough, this someone is anonymous. Here's what whois has to > say: [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Thu Oct 26 23:38:22 2000 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (unknown [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 8239637B479 for ; Thu, 26 Oct 2000 23:38:20 -0700 (PDT) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com for ; Thu, 26 Oct 2000 23:37:49 -0700 From: "David Schwartz" To: Subject: Hackers emailed Microsoft soure code passwords to Russian email address Date: Thu, 26 Oct 2000 23:38:19 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Apparently, hackers had access to Microsoft source code password for three months, having deployed a trojan which made a Microsoft machine email them the passwords. See: http://home.webmaster.com/scitech/ DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 1:11:23 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by hub.freebsd.org (Postfix) with ESMTP id 0F2CE37B479 for ; Fri, 27 Oct 2000 01:11:20 -0700 (PDT) Received: from parish ([62.255.99.145]) by mta02-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20001027081114.GVTC270.mta02-svc.ntlworld.com@parish>; Fri, 27 Oct 2000 09:11:14 +0100 Received: (from mark@localhost) by parish (8.11.0/8.11.0) id e9R8BDE01302; Fri, 27 Oct 2000 09:11:13 +0100 (BST) (envelope-from mark) Date: Fri, 27 Oct 2000 09:11:08 +0100 From: Mark Ovens To: David Schwartz Cc: chat@freebsd.org Subject: Re: Hackers emailed Microsoft soure code passwords to Russian email address Message-ID: <20001027091108.A256@parish> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from davids@webmaster.com on Thu, Oct 26, 2000 at 11:38:19PM -0700 Organization: Total lack of Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Oct 26, 2000 at 11:38:19PM -0700, David Schwartz wrote: > > Apparently, hackers had access to Microsoft source code password > for three months, having deployed a trojan which made a Microsoft machine > email them the passwords. See: http://home.webmaster.com/scitech/ > Seems like they used them to get the Win98 source ;) /* Microsoft(c) Project: Chicago(tm) Projected release-date: Summer 1994 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #define INSTALL HARD char make_prog_look_big[1600000]; void main() { while(!CRASHED) { display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if (first_time_installation) { make_50MB_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_partitions(); search_and_destroy_rest_of_OS2(); hang_system(); } write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if (still_not_crashed) { display_copyright_message(); do_nothing_loop(); basically_run_windows_3x(); do_nothing_loop(); do_nothing_loop(); } } if (detect_cache()) disable_cache(); if (fast_cpu()) { set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, sometimes); } /* printf("Welcome to Windows 3.11"); */ /* printf("Welcome to Windows 95"); */ printf("Welcome to Windows 98"); if (system_ok()) crash(to_dos_prompt); else system_memory = open("a:\\swp0001.swp", O_CREATE); while(something) { sleep(5); get_user_input(); sleep(5); act_on_user_input(); sleep(5); } create_general_protection_fault(); } > DS > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-chat" in the body of the message -- 4.4 - The number of the Beastie ________________________________________________________________ 51.44╟N FreeBSD - The Power To Serve http://www.freebsd.org 2.057╟W My Webpage http://ukug.uk.freebsd.org/~mark mailto:marko@freebsd.org http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 1:47:40 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 91CEF37B479 for ; Fri, 27 Oct 2000 01:47:35 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id BAA10794; Fri, 27 Oct 2000 01:48:03 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp05.primenet.com, id smtpdAAAknaOdv; Fri Oct 27 01:47:56 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id BAA25973; Fri, 27 Oct 2000 01:47:26 -0700 (MST) From: Terry Lambert Message-Id: <200010270847.BAA25973@usr09.primenet.com> Subject: Re: What the ??ck! To: adam@whizkidtech.net (G. Adam Stanislav) Date: Fri, 27 Oct 2000 08:47:25 +0000 (GMT) Cc: chat@FreeBSD.ORG In-Reply-To: <20001026232727.A228@whizkidtech.net> from "G. Adam Stanislav" at Oct 26, 2000 11:27:27 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > And I'm wondering what the heck happened. Then I noticed I mistyped. The > site was actually http://www.frebsd.org/ (just one 'e'). [...] > Strangely enough, this someone is anonymous. Here's what whois has to say: No, it's not. This is just NSIs way of punishing us for breaking up their monopoly, by fragmenting the whois service, so that when you complain, they can tell you how much better things were before their monopoly was compromised. Use either: whois -h whois.networksolutions.com frebsd.org Or the more general (but potentially out of date on some registrars): whois ALL frebsg.org Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 3:47:55 2000 Delivered-To: freebsd-chat@freebsd.org Received: from proxy.tfcc.com (tfcci.com [204.210.226.249]) by hub.freebsd.org (Postfix) with ESMTP id 38A1437B4CF for ; Fri, 27 Oct 2000 03:47:53 -0700 (PDT) Received: (from mail@localhost) by proxy.tfcc.com (8.9.3/8.9.3) id GAA19114 for ; Fri, 27 Oct 2000 06:48:16 -0400 X-Authentication-Warning: proxy.tfcc.com: mail set sender to using -f Received: from icestorm.tfcc.com(192.168.4.115) by proxy.tfcc.com via smap (V2.1/2.1a) id xma019110; Fri, 27 Oct 00 06:47:49 -0400 Date: Fri, 27 Oct 2000 06:47:49 -0400 (EDT) From: Chris Fuhrman X-Sender: cfuhrman@icestorm.tfcc.com To: chat@FreeBSD.ORG Subject: Re: What the ??ck! In-Reply-To: <20001026232727.A228@whizkidtech.net> Message-ID: Organization: 21st Century Communications MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy, This is actually more common than you'd think. For instance there's the following sites: http://www.vokswagen.com http://www.levisjeans.com etc. Silly, really... On Thu, 26 Oct 2000, G. Adam Stanislav wrote: > Hmmm, sheesh, gosh! > > So, I entered what I thought was http://www.freebsd.org/ in my browser, > and here comes this weird page full of banners, plus a JavaScript pop-up > window (gosh, I hate those!). > > And I'm wondering what the heck happened. Then I noticed I mistyped. The > site was actually http://www.frebsd.org/ (just one 'e'). > > Looks to me someone is trying to cash in on FreeBSD's good name, and > hoping others will mistype just as I did. > -- Chris Fuhrman | Twenty First Century Communications cfuhrman@tfcci.com | Software Engineer (W) 614-442-1215 x271 | (F) 614-442-5662 | PGP/GPG Public Key Available on Request To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 4:45:13 2000 Delivered-To: freebsd-chat@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 50BFF37B479 for ; Fri, 27 Oct 2000 04:45:11 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA67456; Fri, 27 Oct 2000 13:44:59 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Terry Lambert Cc: adam@whizkidtech.net (G. Adam Stanislav), chat@FreeBSD.ORG Subject: Re: What the ??ck! References: <200010270847.BAA25973@usr09.primenet.com> From: Dag-Erling Smorgrav Date: 27 Oct 2000 13:44:59 +0200 In-Reply-To: Terry Lambert's message of "Fri, 27 Oct 2000 08:47:25 +0000 (GMT)" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert writes: > No, it's not. This is just NSIs way of punishing us for breaking > up their monopoly, by fragmenting the whois service, so that when > you complain, they can tell you how much better things were before > their monopoly was compromised. Reasonably recent FreeBSD versions have a modified whois(1) command that automatically finds and queries the appropriate whois server, so it's not really such a big issue. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 5:46:10 2000 Delivered-To: freebsd-chat@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id EFD5337B479 for ; Fri, 27 Oct 2000 05:46:07 -0700 (PDT) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id GAA02456; Fri, 27 Oct 2000 06:46:00 -0600 (MDT) Message-Id: <4.3.2.7.2.20001027064510.04400b40@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Oct 2000 06:45:54 -0600 To: "David Schwartz" , From: Brett Glass Subject: Re: Hackers emailed Microsoft soure code passwords to Russian email address In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This shouldn't be a surprise! Microsoft's software leaks like a sieve; it stands to reason that their networks are easily penetrable. --Brett At 12:38 AM 10/27/2000, David Schwartz wrote: > Apparently, hackers had access to Microsoft source code password for three >months, having deployed a trojan which made a Microsoft machine email them >the passwords. See: http://home.webmaster.com/scitech/ > > DS > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-chat" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 6:17:17 2000 Delivered-To: freebsd-chat@freebsd.org Received: from diskfarm.firehouse.net (rdu25-12-043.nc.rr.com [24.25.12.43]) by hub.freebsd.org (Postfix) with ESMTP id 9285137B4C5 for ; Fri, 27 Oct 2000 06:17:15 -0700 (PDT) Received: (from abc@localhost) by diskfarm.firehouse.net (8.11.0/8.11.0) id e9RDLOo14373 for chat@FreeBSD.ORG; Fri, 27 Oct 2000 09:21:24 -0400 (EDT) (envelope-from abc) Date: Fri, 27 Oct 2000 09:21:24 -0400 From: Alan Clegg To: chat@FreeBSD.ORG Subject: Re: What the ??ck! Message-ID: <20001027092124.E2406@diskfarm.firehouse.net> References: <20001026232727.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from cfuhrman@tfcci.com on Fri, Oct 27, 2000 at 06:47:49AM -0400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Unless the network is lying to me again, Chris Fuhrman said: > http://www.vokswagen.com > http://www.levisjeans.com In addition, check out: wwwfreebsd.org (same owner as frebsd.org) wwwapple.com wwwgateway.com wwwcnn.com Leave out a dot, get someone else.... I wonder how much dell paid to get wwwdell.com back... AlanC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 8:21: 4 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by hub.freebsd.org (Postfix) with ESMTP id 81F6537B479 for ; Fri, 27 Oct 2000 08:21:02 -0700 (PDT) Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id RAA23705; Fri, 27 Oct 2000 17:20:35 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id RAA29699; Fri, 27 Oct 2000 17:20:07 +0200 Date: Fri, 27 Oct 2000 17:20:06 +0200 From: Jamie Lokier To: Alfred Perlstein Cc: David Schwartz , Jonathan Lemon , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001027172006.A28504@pcep-jamie.cern.ch> References: <20001025172702.B89038@prism.flugsvamp.com> <20001025161837.D28123@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025161837.D28123@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Oct 25, 2000 at 04:18:37PM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > If a programmer does not ever wish to block under any circumstances, it's > > his obligation to communicate this desire to the implementation. Otherwise, > > the implementation can block if it doesn't have data or an error available > > at the instant 'read' is called, regardless of what it may have known or > > done in the past. > > Yes, and as you mentioned, it was _bugs_ in the operating system > that did this. Not for writes. POLLOUT may be returned when the kernel thinks you have enough memory to do a write, but someone else may allocate memory before you call write(). Or does POLLOUT not work this way? For read, you still want to declare the sockets non-blocking so your code is robust on _other_ operating systems. It's pretty straightforward. -- Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 9: 4: 3 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 12BE037B4C5 for ; Fri, 27 Oct 2000 09:04:01 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9RG3rQ01053; Fri, 27 Oct 2000 09:03:53 -0700 (PDT) Date: Fri, 27 Oct 2000 09:03:53 -0700 From: Alfred Perlstein To: Jamie Lokier Cc: David Schwartz , Jonathan Lemon , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001027090352.Y28123@fw.wintelcom.net> References: <20001025172702.B89038@prism.flugsvamp.com> <20001025161837.D28123@fw.wintelcom.net> <20001027172006.A28504@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001027172006.A28504@pcep-jamie.cern.ch>; from lk@tantalophile.demon.co.uk on Fri, Oct 27, 2000 at 05:20:06PM +0200 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jamie Lokier [001027 08:21] wrote: > Alfred Perlstein wrote: > > > If a programmer does not ever wish to block under any circumstances, it's > > > his obligation to communicate this desire to the implementation. Otherwise, > > > the implementation can block if it doesn't have data or an error available > > > at the instant 'read' is called, regardless of what it may have known or > > > done in the past. > > > > Yes, and as you mentioned, it was _bugs_ in the operating system > > that did this. > > Not for writes. POLLOUT may be returned when the kernel thinks you have > enough memory to do a write, but someone else may allocate memory before > you call write(). Or does POLLOUT not work this way? POLLOUT checks the socketbuffer (if we're talking about sockets), and yes you may still block on mbuf allocation (if we're talking about FreeBSD) if the socket isn't set non-blocking. Actually POLLOUT may be set even if there isn't enough memory for a write in the network buffer pool. > For read, you still want to declare the sockets non-blocking so your > code is robust on _other_ operating systems. It's pretty straightforward. Yes, it's true, not using non-blocking sockets is like ignoring friction in a physics problem, but assuming you have complete control over the machine it shouldn't trip you up that often. And we're talking about readability, not writeability which as you mentioned may block because of contention for the network buffer pool. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 9:40:25 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id EE81B37B479 for ; Fri, 27 Oct 2000 09:40:23 -0700 (PDT) Received: from alumni.caltech.edu ([63.201.176.178]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G3300BR1JPV12@mta6.snfc21.pbi.net> for chat@freebsd.org; Fri, 27 Oct 2000 09:13:07 -0700 (PDT) Date: Fri, 27 Oct 2000 09:21:41 -0700 From: Dan Kegel Subject: Re: kqueue microbenchmark results To: Alan Cox Cc: Jonathan Lemon , Gideon Glass , Simon Kirby , chat@freebsd.org, linux-kernel@vger.kernel.org Reply-To: dank@alumni.caltech.edu Message-id: <39F9AB95.735E26A7@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alan Cox wrote: > > > kqueue currently does this; a close() on an fd will remove any pending > > > events from the queues that they are on which correspond to that fd. > > > > the application of a close event. What can I say, "the fd formerly known > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > since X no longer refers to anything, and the application may have reused > > that fd for another file. > > Which is precisely why you need to know where in the chain of events this > happened. Otherwise if I see > > 'read on fd 5' > 'read on fd 5' > > How do I know which read is for which fd in the multithreaded case That can't happen, can it? Let's say the following happens: close(5) accept() = 5 call kevent() and rebind fd 5 The 'close(5)' would remove the old fd 5 events. Therefore, any fd 5 events you see returned from kevent are for the new fd 5. (I suspect it helps that kevent() is both the only way to bind events and the only way to pick them up; makes it harder for one thread to sneak a new fd into the event list without the thread calling kevent() noticing.) - Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 9:42:46 2000 Delivered-To: freebsd-chat@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A4EBA37B479 for ; Fri, 27 Oct 2000 09:42:43 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9RGgan02182; Fri, 27 Oct 2000 09:42:36 -0700 (PDT) Date: Fri, 27 Oct 2000 09:42:35 -0700 From: Alfred Perlstein To: Dan Kegel Cc: Alan Cox , Jonathan Lemon , Gideon Glass , Simon Kirby , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001027094235.C28123@fw.wintelcom.net> References: <39F9AB95.735E26A7@alumni.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <39F9AB95.735E26A7@alumni.caltech.edu>; from dank@alumni.caltech.edu on Fri, Oct 27, 2000 at 09:21:41AM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Dan Kegel [001027 09:40] wrote: > Alan Cox wrote: > > > > kqueue currently does this; a close() on an fd will remove any pending > > > > events from the queues that they are on which correspond to that fd. > > > > > > the application of a close event. What can I say, "the fd formerly known > > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > > since X no longer refers to anything, and the application may have reused > > > that fd for another file. > > > > Which is precisely why you need to know where in the chain of events this > > happened. Otherwise if I see > > > > 'read on fd 5' > > 'read on fd 5' > > > > How do I know which read is for which fd in the multithreaded case > > That can't happen, can it? Let's say the following happens: > close(5) > accept() = 5 > call kevent() and rebind fd 5 > The 'close(5)' would remove the old fd 5 events. Therefore, > any fd 5 events you see returned from kevent are for the new fd 5. > > (I suspect it helps that kevent() is both the only way to > bind events and the only way to pick them up; makes it harder > for one thread to sneak a new fd into the event list without > the thread calling kevent() noticing.) Yes, that's how it does and should work. Noticing the close() should be done via thread communication/IPC not stuck into kqueue. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 10:36:57 2000 Delivered-To: freebsd-chat@freebsd.org Received: from kizmiaz.dis.org (kizmiaz.dis.org [216.240.45.60]) by hub.freebsd.org (Postfix) with ESMTP id 0B13D37B479 for ; Fri, 27 Oct 2000 10:36:53 -0700 (PDT) Received: from localhost (almus@localhost) by kizmiaz.dis.org (8.9.3/8.9.3) with SMTP id KAA12225; Fri, 27 Oct 2000 10:36:20 -0700 (PDT) Date: Fri, 27 Oct 2000 10:36:19 -0700 (PDT) From: Almus To: "Nicole Harrington." Cc: Brett Glass , Ceren Ercen , chat@FreeBSD.ORG Subject: Re: bondage bsd daemon image In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thats cute.. it would make a good t-shirt, first we would need to get Kirk's permission.. then somone would have to redraw it to make it cleaner, and large enough to go on a T and still look good.. -Almus On Thu, 26 Oct 2000, Nicole Harrington. wrote: > > On 26-Oct-00 Almus wrote: > > I havent seen this one.. anyone have a direct link? > > > > -Almus > > > Ahha... It wasn't on kirk's site... Here's a link > > http://www.freebsd.org/gifs/coverb.jpg > > > Nicole > > > > > > > On Wed, 25 Oct 2000, Nicole Harrington. wrote: > > > >> > >> On 26-Oct-00 Almus wrote: > >> > The origonal "FREE BSD" with the space on the yellow background was an > >> > obvious referance to the "FREE KEVIN" campain, and was kinda a joke (it > >> > was a shirt made for defcon) as that is out of date, I am considering > >> > dropping back to the "FreeBSD" probably in white on a black background.. > >> > what does everyone think? > >> > "If only I could get myself unchained from X Windows...." > >> > I think that quote is great.. and will add some of the humor back in, as > >> > the origonal joke the shirt was designed around is out of date now.. > >> > again.. what does everyonr think? I will make whichever shirt people would > >> > be more likely to buy.. > >> > (I have several of the defcon version which I am no longer selling, so I > >> > am making these for you, not me..) > >> > > >> > -Almus > >> > >> I really like the cover from the Japan magazine shown on Kirk's site of BSD > >> Images. It has a picture of beastie behind bars with FreeBSD printed > >> underneath. > >> > >> I would love to see that as a shirt as well. > >> > >> Nicole > >> > >> > >> > >> > > >> > On Wed, 25 Oct 2000, Brett Glass wrote: > >> > > >> >> At 04:02 PM 10/24/2000, Ceren Ercen wrote: > >> >> > >> >> >http://www.satindeath.net/boundchuck.jpg > >> >> > > >> >> >He's removing the mention of DefCon from the bottom of the shirt. And if > >> >> >anyone can come up with a better slogan than "The only way to lock up > >> >> >this > >> >> >OS", he's open to suggestions. > >> >> > >> >> How about: > >> >> > >> >> > >> >> "If only I could get myself unchained from X Windows...." > >> >> > >> >> > >> >> In any case, he should remove the space between "FREE" and "BSD", or > >> >> (better) use the canonical mixed-case spelling ("FreeBSD"). > >> >> > >> >> --Brett > >> >> > >> >> > >> > > >> > -- > >> > It is my Firm Belief that it's a mistake > >> > to hold Firm Beliefs! > >> > <-Goth.Code98-> almus@dis.org www.dis.org/almus > >> > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 > >> > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT > >> > -- > >> > > >> > Send private encrypted e-mail - Freedom 1.1 > >> > www.zks.net/clickthrough/click.asp?partner_id=111 > >> > > >> > > >> > > >> > > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org > >> > with "unsubscribe freebsd-chat" in the body of the message > >> > >> nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ > >> webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ > >> nicole@deviantimages.com // \\ http://www.deviantimages.com/ > >> > >> ---------------------------(((---(((----------------------------------------- > >> > >> -- Powered by Coka-Cola and FreeBSD -- > >> -- Strong enough for a man - But made for a Woman -- > >> -- "I drank WHAT ?!" - Socrates -- > >> Hmm You seem better - "been giving myself shock treatments" Up the Voltage! > >> ----------------------------------------------------------------------------- > >> > >> > > > > -- > > It is my Firm Belief that it's a mistake > > to hold Firm Beliefs! > > <-Goth.Code98-> almus@dis.org www.dis.org/almus > > uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 > > dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT > > -- > > > > Send private encrypted e-mail - Freedom 1.1 > > www.zks.net/clickthrough/click.asp?partner_id=111 > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-chat" in the body of the message > > nicole@unixgirl.com |\ __ /| (`\ http://www.unixgirl.com/ > webmistress@dangermouse.org | o_o |__ ) ) http://www.dangermouse.org/ > nicole@deviantimages.com // \\ http://www.deviantimages.com/ > > ---------------------------(((---(((----------------------------------------- > > -- Powered by Coka-Cola and FreeBSD -- > -- Strong enough for a man - But made for a Woman -- > -- "I drank WHAT ?!" - Socrates -- > Hmm You seem better - "been giving myself shock treatments" Up the Voltage! > ----------------------------------------------------------------------------- > > -- It is my Firm Belief that it's a mistake to hold Firm Beliefs! <-Goth.Code98-> almus@dis.org www.dis.org/almus uU1iba4baSarcbbahbaa874vZMPFAajbuvgihqc#38F46a6p3 dba5FHmaiuDeibJ#ca#pNaspk7EVpsEtU3afbFabGacaeusUT -- Send private encrypted e-mail - Freedom 1.1 www.zks.net/clickthrough/click.asp?partner_id=111 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 16:52:11 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 8963A37B479 for ; Fri, 27 Oct 2000 16:52:07 -0700 (PDT) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id QAA06879; Fri, 27 Oct 2000 16:08:42 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpdAAAaJaipm; Fri Oct 27 16:07:38 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA29462; Fri, 27 Oct 2000 16:08:12 -0700 (MST) From: Terry Lambert Message-Id: <200010272308.QAA29462@usr01.primenet.com> Subject: Re: kqueue microbenchmark results To: dank@alumni.caltech.edu Date: Fri, 27 Oct 2000 23:08:12 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), jlemon@flugsvamp.com (Jonathan Lemon), gid@cisco.com (Gideon Glass), sim@stormix.com (Simon Kirby), chat@FreeBSD.ORG, linux-kernel@vger.kernel.org In-Reply-To: <39F9AB95.735E26A7@alumni.caltech.edu> from "Dan Kegel" at Oct 27, 2000 09:21:41 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Which is precisely why you need to know where in the chain of events this > > happened. Otherwise if I see > > > > 'read on fd 5' > > 'read on fd 5' > > > > How do I know which read is for which fd in the multithreaded case > > That can't happen, can it? Let's say the following happens: > close(5) > accept() = 5 > call kevent() and rebind fd 5 > The 'close(5)' would remove the old fd 5 events. Therefore, > any fd 5 events you see returned from kevent are for the new fd 5. > > (I suspect it helps that kevent() is both the only way to > bind events and the only way to pick them up; makes it harder > for one thread to sneak a new fd into the event list without > the thread calling kevent() noticing.) Strictly speaking, it can happen in two cases: 1) single acceptor thread, multiple worker threads 2) multiple anonymous "work to do" threads In both these cases, the incoming requests from a client are given to any thread, rather than a particular thread. In the first case, we can have (id:executer order:event): 1:1:open 5 2:2:read 5 3:4:read 5 2:3:close 5 If thread 2 processes the close event before thread 3 processes the read event, then when thread 3 attempts procssing, it will fail. Technically, this is a group ordering problem in the design of the software, which should instead queue all events to a dispatch thread, and the threads should use IPC to serialize processing of serial events. This is similar to the problem with async mounted FS recovery in event of a crash: without ordering guarantees, you can only get to a "good" state, not necessarily "the one correct state". In the second case, we can have: 1:2:read 5 2:1:open 5 3:4:read 5 2:3:close 5 This is just a non-degenerate form of the first case, where we allow thread 1 and all other threads to be identical, and don't serialize open state initialization. The NetWare for UNIX system uses this model. The benefit is that all user space threads can be identical. This means that I can use either threads or processes, and it won't matter, so my software can run on older systems that lack "perfect" threads models, simply by using processes, and putting client state into shared memory. In this case, there is no need for inter-thread synchronization; instead, we must insist that events be dispatched sequentially, and that the events be processed serially. This effectively requires event processing completion notigfication from user space to kernel space. In NetWare for UNIX, this was accomplished using a streams MUX which knew that the NetWare protocol was request-response. This also permitted "busy" responses to be turned around in kernel space, without incurring a kernel-to-user space scheduling penalty. It also permitted "piggyback", where an ioctl to the mux was used to respond, and combined sending a response with the next read. This reduced protection domain crossing and the context switch overhead by 50%. Finally, the MUX sent requests to user space in LIFO order. This approach is called "hot engine scheduling", in that the last reader in from user space is the most likely to have its pages in core, so as to not need swapping to handle the next request. I was architect of much of the process model discussed above; as you can see, there are some significant performance wins to be had by building the right interfaces, and putting the code on the right side of the user/kernel boundary. In any case, the answer is that you can not assume that the only correct way to solve a problem like event inversion is serialization of events in user space (or kernel space). This is not strictly a "threaded application implementation" issue, and it is not strictly a kernel serialization of event delivery issue. Another case, which NetWare did not handle, is that of rejected authentication. Even if you went with the first model, and forced your programmers to use expensive inter-thread synchronization, or worse, bound each client to a single thread in the server, thus rendering the system likely to have skewed thread load, getting worse the longer the connection was up, you would still have the problem of rejected authentication. A client might attempt to send authentication followed by commands in the same packet series, without waiting for an explicit ACK after each one (i.e. it might attempt to implement a sliding window over a virtual circuit), and the system on the other end might dilligently queue the events, only to have the authentication be rejected, but with packets queued already to user space for processing, assuming serialization in user space. You would then need a much more complex mechanism, to allow you to invalidate an already queued event to another thread, which you don't know about in your thread, before you release the interlock. Otherwise the client may get responses without a valid authentication. You need look no further than LDAPv3 for an example of a protocol where this is possible (assuming X.509 certificate based SASL authentication, where authentication is not challenge-response, but where it consists solely of presenting ones certificate). When considering this API, you have to consider more than just the programming models you think are "right", you have to consider all of the that are possible. All in all, this is an interesting discussion. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 17:23:36 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 4E25E37B4C5 for ; Fri, 27 Oct 2000 17:23:33 -0700 (PDT) Received: from alumni.caltech.edu ([63.201.176.178]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G3400E7X640HL@mta5.snfc21.pbi.net> for chat@FreeBSD.ORG; Fri, 27 Oct 2000 17:16:49 -0700 (PDT) Date: Fri, 27 Oct 2000 17:24:56 -0700 From: Dan Kegel Subject: Re: kqueue microbenchmark results To: Terry Lambert Cc: Alan Cox , Jonathan Lemon , Gideon Glass , Simon Kirby , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Reply-To: dank@alumni.caltech.edu Message-id: <39FA1CD8.6C6ABAEE@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200010272308.QAA29462@usr01.primenet.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > > > Which is precisely why you need to know where in the chain of events this > > > happened. Otherwise if I see > > > 'read on fd 5' > > > 'read on fd 5' > > > How do I know which read is for which fd in the multithreaded case > > > > That can't happen, can it? Let's say the following happens: > > close(5) > > accept() = 5 > > call kevent() and rebind fd 5 > > The 'close(5)' would remove the old fd 5 events. Therefore, > > any fd 5 events you see returned from kevent are for the new fd 5. > > Strictly speaking, it can happen in two cases: > > 1) single acceptor thread, multiple worker threads > 2) multiple anonymous "work to do" threads > > In both these cases, the incoming requests from a client are > given to any thread, rather than a particular thread. > > In the first case, we can have (id:executer order:event): > > 1:1:open 5 > 2:2:read 5 > 3:4:read 5 > 2:3:close 5 > > If thread 2 processes the close event before thread 3 processes > the read event, then when thread 3 attempts procssing, it will > fail. You're not talking about kqueue() / kevent() here, are you? With that interface, thread 2 would not see a close event; instead, the other events for fd 5 would vanish from the queue. If you were indeed talking about kqueue() / kevent(), please flesh out the example a bit more, showing who calls kevent(). (A race that *can* happen is fd 5 could be closed by another thread after a 'read 5' event is pulled from the event queue and before it is processed, but that could happen with any readiness notification API at all.) - Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 19:23:10 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id C77CB37B65E for ; Fri, 27 Oct 2000 19:23:03 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 27 Oct 2000 19:21:42 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e9S2Mul44415; Fri, 27 Oct 2000 19:22:56 -0700 (PDT) (envelope-from cjc) Date: Fri, 27 Oct 2000 19:22:56 -0700 From: "Crist J . Clark" To: Chris Fuhrman Cc: chat@FreeBSD.ORG Subject: Re: What the ??ck! Message-ID: <20001027192256.D75251@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: <20001026232727.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from cfuhrman@tfcci.com on Fri, Oct 27, 2000 at 06:47:49AM -0400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Oct 27, 2000 at 06:47:49AM -0400, Chris Fuhrman wrote: > > Howdy, > > This is actually more common than you'd think. For instance there's the > following sites: > > http://www.vokswagen.com > http://www.levisjeans.com $ dig www.levisjeans.com ; <<>> DiG 8.3 <<>> www.levisjeans.com ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; www.levisjeans.com, type = A, class = IN ;; Total query time: 56 msec ;; FROM: 149.211.6.64.reflexcom.com to SERVER: default -- 64.6.204.18 ;; WHEN: Fri Oct 27 19:21:20 2000 ;; MSG SIZE sent: 36 rcvd: 36 $ whois levisjeans.com [snip] Registrant: Levi-Strauss & Co (LEVISJEANS-DOM) 1155 Battery Street San Francisco, CA 94111 US Domain Name: LEVISJEANS.COM [snip] What'd I miss? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 22:42:26 2000 Delivered-To: freebsd-chat@freebsd.org Received: from soup.thpoon.com (cr103675-a.bloor1.on.wave.home.com [24.114.152.71]) by hub.freebsd.org (Postfix) with SMTP id DE12D37B479 for ; Fri, 27 Oct 2000 22:42:24 -0700 (PDT) Received: (qmail 82791 invoked from network); 28 Oct 2000 05:42:24 -0000 Received: from unknown (HELO tea.thpoon.com) (mail@192.168.1.2) by cr103675-a.bloor1.on.wave.home.com with SMTP; 28 Oct 2000 05:42:24 -0000 Received: from antipode by tea.thpoon.com with local (Exim 3.12 #1 (Debian)) id 13pOl5-0000ZS-00 for ; Sat, 28 Oct 2000 01:42:23 -0400 To: chat@FreeBSD.ORG Subject: german, anyone From: Arcady Genkin X-Face: 0=A/O5-+sE[Tf%X>rYr?Y5LD4,:^'jaJ!4jC&UR*ZrrK2>^`g22Qeb]!:d;}2YJ|Hq"LHdF OX`jWX|AT-WVFQ(TPhFVak)0nt$aEdlOq=1~D,:\z5QlVOrZ2(H,mKg=Xr|'VlHA="r Organization: thpoon.com Mail-Copies-To: never Date: 28 Oct 2000 01:42:23 -0400 Message-ID: <87wvet34jk.fsf@tea.thpoon.com> Lines: 5 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I wonder what this one says: http://www.koehntopp.de/kris/msad.jpg -- Arcady Genkin Don't read everything you believe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Fri Oct 27 23: 8: 5 2000 Delivered-To: freebsd-chat@freebsd.org Received: from heorot.1nova.com (sub24-23.member.dsl-only.net [63.105.24.23]) by hub.freebsd.org (Postfix) with ESMTP id A5F1237B479 for ; Fri, 27 Oct 2000 23:08:03 -0700 (PDT) Received: by heorot.1nova.com (Postfix, from userid 1000) id 7DA1E329E; Thu, 26 Oct 2000 22:31:58 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by heorot.1nova.com (Postfix) with ESMTP id 5A763329D; Thu, 26 Oct 2000 22:31:58 +0000 (GMT) Date: Thu, 26 Oct 2000 22:31:58 +0000 (GMT) From: Rick Hamell To: Arcady Genkin Cc: chat@FreeBSD.ORG Subject: Re: german, anyone In-Reply-To: <87wvet34jk.fsf@tea.thpoon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I wonder what this one says: > http://www.koehntopp.de/kris/msad.jpg I think it says: "A back up system must match your needs." :) Please remeber that it's been nearly 10 years since I took a German class though... :) Rick ******************************************************************* Rick's FreeBSD Web page http://heorot.1nova.com/freebsd Ace Logan's Hardware Guide http://www.shatteredcrystal.net/hardware ***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 Fri Oct 27 23:57:50 2000 Delivered-To: freebsd-chat@freebsd.org Received: from winnie.fit.edu (fit.edu [163.118.5.1]) by hub.freebsd.org (Postfix) with ESMTP id 3697A37B479 for ; Fri, 27 Oct 2000 23:57:48 -0700 (PDT) Received: from netzero.net (rm305w-a.campbell.fit.edu [163.118.216.111]) by winnie.fit.edu (8.9.1/8.9.1) with ESMTP id CAA09439 for ; Sat, 28 Oct 2000 02:58:07 -0400 (EDT) Message-ID: <39FA7963.FC4CE5E1@netzero.net> Date: Sat, 28 Oct 2000 02:59:47 -0400 From: Kevin Brunelle X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: chat@freebsd.org Subject: Re: german, anyone References: <87wvet34jk.fsf@tea.thpoon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Arcady Genkin, I read this a while ago and heard the following translation was close from a person who speaks very good German. "An open operating system does not just have advantages." (This is the big text.) "An open operating system sometimes just mutates. Instead Windows 2000 offers all services from a single source. This saves time and consequently really money. More info under www.microsoft.com/germany/windows2000" (This is the small block of text.) And yes, that is "really money", not 'real money', don't ask me. I forget where I got the first translation from. But my friend told me it was correct. -- -Kevin Don't open your eyes, you won't like what you see; the devils of truth steal the souls of the free... Don't open your eyes, take it from me -- I have found you can find happiness in slavery... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 3:12:13 2000 Delivered-To: freebsd-chat@freebsd.org Received: from freenix.no (atreides.freenix.no [213.188.21.6]) by hub.freebsd.org (Postfix) with ESMTP id 0E0C337B479 for ; Sat, 28 Oct 2000 03:12:11 -0700 (PDT) Received: (from shamz@localhost) by freenix.no (8.9.3/8.9.3) id MAA68687 for chat@FreeBSD.ORG; Sat, 28 Oct 2000 12:11:59 +0200 (CEST) (envelope-from shamz) Date: Sat, 28 Oct 2000 12:11:59 +0200 From: Shaun Jurrens To: chat@FreeBSD.ORG Subject: Re: german, anyone Message-ID: <20001028121159.K14117@atreides.freenix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Operating-System: FreeBSD 4.1-STABLE X-Philosophy: If you can read this, you're too close. Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The title reads: "An open operating system does not just have advantages" (literally: an open operating system has not only advanteges) The text: "An open operating system can occassionally mutate. With Windows 2000, however, all of the services and (services|daemons)* come from one source (literally hand). That saves time and therefore money, really. More info under ....(bla.mircrosleaze.com)" The question as to whether "wirklich" is an adverb or an adjective is a matter of interpretation. There is no -ly suffix marker in German to make the distinction definitive in such cases, but if one "really saves money" or "saves _real_ (i.e. a lot) money" with M$ is kind of a mute point anyway. *Note: "Services" is "new-German" (trendy suit talk) and is much the same as "Dienste". -- Yours truly, Shaun D. Jurrens shaun@shamz.net shamz@freenix.no IRCNET nick: shamz #chillout #unix #FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 7:30:28 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D6FF37B479 for ; Sat, 28 Oct 2000 07:30:25 -0700 (PDT) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 13pX03-0007ki-00; Sat, 28 Oct 2000 16:30:23 +0200 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.0/8.11.0) id e9SDmkV50153 for freebsd-chat@freebsd.org; Sat, 28 Oct 2000 15:48:46 +0200 (CEST) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: german, anyone Date: Sat, 28 Oct 2000 13:48:46 +0000 (UTC) Message-ID: <8telfu$1gv0$1@kemoauc.mips.inka.de> References: <20001028121159.K14117@atreides.freenix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-chat@freebsd.org Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Shaun Jurrens wrote: > The text: > "An open operating system can occassionally mutate. With Windows > 2000, however, all of the services and (services|daemons)* come from > one source (literally hand). That saves time and therefore money, > really. More info under ....(bla.mircrosleaze.com)" > > The question as to whether "wirklich" is an adverb or an adjective is a > matter of interpretation. There is no -ly suffix marker in German to make > the distinction definitive in such cases, However, this is almost always disambiguated by the lack of inflectional suffixes for the adverb. If it were an adjective, it would say "Das spart ... wirkliches Geld". Which would mean "real money" in the sense of not counterfeited. You can't translate the English colloquial idiom "real money" (a lot of money) literally. If you look at the way "wirklich Geld sparen" and "saving real money" are used in the respective languages, you'll see that they are equivalent, although their literal meaning isn't quite the same. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 9:33:27 2000 Delivered-To: freebsd-chat@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 26C0537B479; Sat, 28 Oct 2000 09:33:22 -0700 (PDT) Received: from [194.207.93.139] by gate.trident-uk.co.uk for freebsd-announce@freebsd.org id QAA09832; Sat Oct 28 16:32:18 2000 Organization: Psi-Domain Ltd. Subject: Open hardware standards for FreeBSD?? Date: Sat, 28 Oct 2000 17:37:30 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00102817380200.00919@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: freebsd-announce@freebsd.org, freebsd-chat@freebsd.org From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fellow FreeBSD'ers Would anyone out their be *interested* in me and anyone else who wants to join in starting some sort of FreeBSD hardware standards body? I am writing to this list in order to propose an industry-wide set of performance standards for FreeBSD based hardware suppliers. Whilst attempting to rate each and every product that our company provides in terms of desired application (e.g. Cluster Nodes, Database Server, Desktop, File Server, Mail Server, Printer Server, Router, Web Server, etc.), and in terms of desired performance, I thought that we (FreeBSD hardware suppliers) should have some sort of 'standards' base. I'm not talking *raw* performance figures against each type of FreeBSD system provided (like SPECcpu2000, etc. from www.spec.org) like Sun and the like use, but maybe a classification based on application. Thus, our customers would instantly be re-assured that a box from XXX company would perform or be able to do similar tasks to a box from YYY company whilst still complying to their required specifications - just by checking its classification rating. To make things clearer - say we agreed that for a box (of any spec) to perform adequately well as a Web server, it would need to be able to handle X number of page views a minute (or second, or whatever). Then, for each box in our varying product ranges that could serve the X pages per minute, we could rubber-stamp them as being fit for the purpose of Web serving. This concept could be further extended to include sub-categorisations like 'Web Server Class 1', 'Web Server Class II', and so on. (Ok, page views a minute might not be the best example, as performance really comes down to NIC, cabling and bandwidth - but I hope that you get picture!) Is this a good thing?? Let me know your thoughts. Regards, -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 15:16:20 2000 Delivered-To: freebsd-chat@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 0F21C37B479 for ; Sat, 28 Oct 2000 15:16:19 -0700 (PDT) Received: by peorth.iteration.net (Postfix, from userid 1001) id 1B08E5730B; Sat, 28 Oct 2000 17:16:19 -0500 (CDT) Date: Sat, 28 Oct 2000 17:16:19 -0500 From: "Michael C . Wu" To: chat@freebsd.org Subject: BSDCon Pics from the Taiwanese guy Message-ID: <20001028171618.A86873@peorth.iteration.net> Reply-To: "Michael C . Wu" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For People outside of Asia or on Internet2 http://ieeecs.ece.utexas.edu/~keichii/pict/bsdcon/ (Taiwan Beer...) For people in Taiwan or other Asian locations, you may wish to try: (the upload will be finished in about 2 hours) http://freebsd.ite.ntnu.edu.tw/~keichii/pict/bsdcon/ -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 15:20:21 2000 Delivered-To: freebsd-chat@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 7E82437B479 for ; Sat, 28 Oct 2000 15:20:19 -0700 (PDT) Received: by peorth.iteration.net (Postfix, from userid 1001) id 833245730B; Sat, 28 Oct 2000 17:20:19 -0500 (CDT) Date: Sat, 28 Oct 2000 17:20:19 -0500 From: "Michael C . Wu" To: chat@freebsd.org Subject: Someone got a pic of me speaking at I18N talk? Message-ID: <20001028172019.A86896@peorth.iteration.net> Reply-To: "Michael C . Wu" References: <20001028171618.A86873@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001028171618.A86873@peorth.iteration.net>; from keichii@iteration.net on Sat, Oct 28, 2000 at 05:16:19PM -0500 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was wondering if the people who took pictures of C.L. Kao, Clive Lin, and myself speaking at the BSDCon2000 I18N talk could give me files or copies of those pics. Thanks! :) Michael, -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 21:44:18 2000 Delivered-To: freebsd-chat@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id D11C237B479 for ; Sat, 28 Oct 2000 21:44:13 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9T4i2k87433; Sun, 29 Oct 2000 15:14:02 +1030 (CST) (envelope-from grog) Date: Sun, 29 Oct 2000 15:14:02 +1030 From: Greg Lehey To: Shaun Jurrens Cc: chat@FreeBSD.ORG Subject: Re: german, anyone Message-ID: <20001029151402.I68266@wantadilla.lemis.com> References: <20001028121159.K14117@atreides.freenix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001028121159.K14117@atreides.freenix.no>; from shaun@shamz.net on Sat, Oct 28, 2000 at 12:11:59PM +0200 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday, 28 October 2000 at 12:11:59 +0200, Shaun Jurrens wrote: > The title reads: > > "An open operating system does not just have advantages" > (literally: an open operating system has not only advanteges) > > The text: > "An open operating system can occassionally mutate. With Windows > 2000, however, all of the services and (services|daemons)* come from > one source (literally hand). That saves time and therefore money, > really. More info under ....(bla.mircrosleaze.com)" > > The question as to whether "wirklich" is an adverb or an adjective is a > matter of interpretation. No, in this case there's no room for interpretation. > There is no -ly suffix marker in German to make the distinction > definitive in such cases, Well, sort of. There's -lich, which is etymologically related, and which tends to imply an adverb. The fact is that "wirklich" is one of the few words in German which is used almost only as an adverb. Although it can be used as an adjective, there are few examples. After a lot of thinking, my wife finally came up with "Im wirklichen Leben" ("in real life"). The real issue here, though, is that adjectives decline, and adverbs don't. If it were an adjective, it would have to agree in case, number and gender with the noun (Geld == money, accusative singular neuter): "Das spart Zeit und somit wirklich*es* Geld". That would sound really funny, though. If they really wanted to say "real", they might have tried the word for "real", "echt": "Das spart Zeit und somit echt Geld" (adverbial) or "Das spart Zeit und somit echtes Geld" (adjectival). The former sounds acceptable, the latter sounds as if you are saving real money rather than fake money. All that aside, the text of the ad sounds a bit funny anyway. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 21:50: 2 2000 Delivered-To: freebsd-chat@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 7389B37B479; Sat, 28 Oct 2000 21:49:57 -0700 (PDT) Received: by puck.firepipe.net (Postfix, from userid 1000) id 2094A18A9; Sat, 28 Oct 2000 23:50:57 -0500 (EST) Date: Sat, 28 Oct 2000 23:50:57 -0500 From: Will Andrews To: "R. Imura" Cc: ports@FreeBSD.org, developers@FreeBSD.org, chat@FreeBSD.org Subject: Re: cvs commit: doc/en_US.ISO_8859-1/books/handbook authors.ent doc/en_US.ISO_8859-1/books/handbook/contrib chapter.sgml doc/en_US.ISO_8859-1/books/handbook/staff chapter.sgml Message-ID: <20001028235057.T20599@puck.firepipe.net> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , "R. Imura" , ports@FreeBSD.org, developers@FreeBSD.org, chat@FreeBSD.org References: <200010290446.VAA31044@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010290446.VAA31044@freefall.freebsd.org>; from imura@FreeBSD.org on Sat, Oct 28, 2000 at 09:46:40PM -0700 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Oct 28, 2000 at 09:46:40PM -0700, R. Imura wrote: > Log: > Move my name from staff list to contributor list. > I'll retire from comitter work. > > Thanks! > > - Ryuichiro IMURA > age: 422 days > commit counts: 291 times (exclude this commit) > closed PRs: 69 PRs > typos: many.. :) I'll be the first to say THANK YOU for contributing over this time. It's indeed sad that you have decided to retire. But I (and probably many others) appreciate that you are at least saying something instead of simply disappearing into the night like many others... :-) Good luck, -- Will Andrews - Physics Computer Network wench To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message From owner-freebsd-chat Sat Oct 28 22:12:29 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mail.af.airnet.ne.jp (mail.af.airnet.ne.jp [210.159.66.49]) by hub.freebsd.org (Postfix) with ESMTP id D490C37B479; Sat, 28 Oct 2000 22:12:25 -0700 (PDT) Received: from imura.af.airnet.ne.jp (tok240.airnet.ne.jp [210.159.88.240]) by mail.af.airnet.ne.jp (8.8.8/3.6W/06/13/98-AF.AIRNET.NE.JP) with ESMTP id OAA08128; Sun, 29 Oct 2000 14:12:23 +0900 Posted-Date: Sun, 29 Oct 2000 14:14:03 +0900 (JST) To: will@physics.purdue.edu Cc: ports@FreeBSD.org, developers@FreeBSD.org, chat@FreeBSD.org Subject: Re: cvs commit: doc/en_US.ISO_8859-1/books/handbook authors.ent doc/en_US.ISO_8859-1/books/handbook/contrib chapter.sgml doc/en_US.ISO_8859-1/books/handbook/staff chapter.sgml From: "R. Imura" In-Reply-To: <20001028235057.T20599@puck.firepipe.net> References: <200010290446.VAA31044@freefall.freebsd.org> <20001028235057.T20599@puck.firepipe.net> X-Mailer: Mew version 1.94b20 on Emacs 19.34 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?= X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001029141402B.imura@cs.titech.ac.jp> Date: Sun, 29 Oct 2000 14:14:02 +0900 X-Dispatcher: imput version 990401(IM113) Lines: 13 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'll be the first to say THANK YOU for contributing over this time. > It's indeed sad that you have decided to retire. But I (and probably > many others) appreciate that you are at least saying something instead > of simply disappearing into the night like many others... :-) > > Good luck, I did not prepare any words of gratitude to you at all. :) Thanks, thanks. Thanks, again! Sincerely, - R. Imura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message