From owner-freebsd-arch Sun Feb 18 0:46:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 1789137B67D for ; Sun, 18 Feb 2001 00:46:13 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1I8jWH09074; Sun, 18 Feb 2001 00:45:32 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: "Daniel C. Sobral" Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from "Daniel C. Sobral" of "Sun, 18 Feb 2001 14:54:03 +0900." <3A8F637B.45C18CFC@newsguy.com> Date: Sun, 18 Feb 2001 00:45:32 -0800 Message-ID: <9070.982485932@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I disagree. One of FreeBSD strong points with many users is that we are > not a "distribution", a bundle of assorted software thrown in together, > but a whole OS, tightly integrated and balanced, to which the user may > add extra software if he wants to. I don't think you actually need to disagree with any of this. What you're talking about here is a "policy", e.g. a set of sets which describes what "FreeBSD is" and something which is quite important. It's also, however, something which should also go at least one level above all the mechanism foo. What we have now is a hard coded policy which can't be changed without editing Makefiles and such. We further justify the existence of all that hard-coded mess to ourselves, even though it often gets in our own way, on the grounds that we're taking a firm stand on what FreeBSD means to the user and that what we have works well enough for delivering a single, well-defined "FreeBSD" product. None of those fast and loose "Linux distro" scenes for us, no sir! Sadly, such arguments are also woefully deficient from a perspective of good software engineering. We shouldn't be setting policy based on the limits of our build and release technology, that's backwards. The system should instead be designed with as much flexiblity as it's reasonable to have and let policy decisions be largely as a configuration function. To put it more simply, just because our software might allow for all sorts of modular plug-and-play configuration behind the scenes doesn't mean that end-users need actually see ANY of that. Even if our /usr/src grew into a fully modular package-fed framework which did everything the current /usr/src did and more tomorrow, you would still see FreeBSD installations and "make world" runs which looked exactly like the end-product of a make world or full install today. POLA would more or less demand that what constituted FreeBSD, in all its current perl, sendmail and uucp containing glory, did not change at all until we had the full chance to seriously consider changing such policies. Until we actually change the underlying build technology, however, actually changing these policies remains painful or not easily reversible on a per-developer basis, so we go round and round arguing about the individual items. Which is where I first came into all this discussion. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 1: 3:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 14F4237B401 for ; Sun, 18 Feb 2001 01:03:38 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1I92MW01403; Sun, 18 Feb 2001 02:02:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102180902.f1I92MW01403@harmony.village.org> To: Jordan Hubbard Subject: Re: Moving Things [was Re: List of things to move from main tree] Cc: "Daniel C. Sobral" , Mark Murray , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 00:45:32 PST." <9070.982485932@winston.osd.bsdi.com> References: <9070.982485932@winston.osd.bsdi.com> Date: Sun, 18 Feb 2001 02:02:22 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan, I'd like to point out that making FreeBSD more modular doesn't necessarily mean that we have to change the policy we have hard coded into the Makefiles. We can and do subset things more easily than that. NetBSD builds everything during make build, but has a better layering of system components than FreeBSD, for example. I'm not saying thta it is good or bad. There are pros and cons to both ways. I have a kludge script that just install the minimal (for a suitible definition of minimal) set of files on a target system. I doubt they rise to the level that they could be used for packageNG, but stranger things have happened :-) You do make an excellent point that we do have this policy hard coded into the make files. We have limited support for subsetting in the Makefiles. We can support one set of subsetting for the source upgrades and one class for the binary folks. This may or may not be desirable from a support point of view, but it is what we already do now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 1:20:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id F2E4A37B491 for ; Sun, 18 Feb 2001 01:20:20 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1I9JdH11289; Sun, 18 Feb 2001 01:19:39 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Warner Losh Cc: "Daniel C. Sobral" , Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Warner Losh of "Sun, 18 Feb 2001 02:02:22 MST." <200102180902.f1I92MW01403@harmony.village.org> Date: Sun, 18 Feb 2001 01:19:39 -0800 Message-ID: <11284.982487979@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to point out that making FreeBSD more modular doesn't > necessarily mean that we have to change the policy we have hard coded > into the Makefiles. We can and do subset things more easily than Absolutely, we're in violent agreement on that point. I'm just suggesting that instead of having the policy be represented by SUBDIR lines in Makefiles, it should instead be something like this: FreeBSD-standard RELENG_4 This is what constitutes the "standard" version of FreeBSD bin lib usr etc installer And when I say something "like" that I'm really reaching because this is a seriously contrived example which doesn't even begin to enumerate all the various types of meta-data which one would need to describe "the standard release of FreeBSD." I'm not even saying it would be in XML (please put those spears down), only that it would live outside of the actual build mechanism and simply become configuration data. Such a thing would also finally get rid of all those evil and not-very-comprehensive NO_FOO variables in the source tree, as if any of us truly needed to see a list of our current build system's shortcomings. And yes, I do also realize that coming up with something even half as sophisticated as what I've described so far will take more than lots of mere hand-waving on the subject. Progress often moves in strange ways, so let's just see where all this goes. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 1:26: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 12E3937B503 for ; Sun, 18 Feb 2001 01:26:05 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1I9Q1W01716; Sun, 18 Feb 2001 02:26:01 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102180926.f1I9Q1W01716@harmony.village.org> To: Jordan Hubbard Subject: Re: Moving Things [was Re: List of things to move from main tree] Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 01:19:39 PST." <11284.982487979@winston.osd.bsdi.com> References: <11284.982487979@winston.osd.bsdi.com> Date: Sun, 18 Feb 2001 02:26:01 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <11284.982487979@winston.osd.bsdi.com> Jordan Hubbard writes: : Absolutely, we're in violent agreement on that point. I'm just : suggesting that instead of having the policy be represented by : SUBDIR lines in Makefiles, it should instead be something like : this: What I have right now is approximately: make buildworld . foo.conf for i in $subdirs; do (cd $i ; make install) done where foo.conf does the installation. There are lots of flaws with it, but it does let me build 8M flash parts that boot (but don't do much useful). The how of this is just eyecandy. :-) however, to be accepted, the eyecandy has to be sweet enough and survive the bikeshedding and still not look too bad. don't know if I have that in me :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 2:11:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 3009637B503 for ; Sun, 18 Feb 2001 02:11:26 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1I9b9957438; Sun, 18 Feb 2001 11:37:13 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102180937.f1I9b9957438@gratis.grondar.za> To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <11284.982487979@winston.osd.bsdi.com> In-Reply-To: <11284.982487979@winston.osd.bsdi.com> ; from Jordan Hubbard "Sun, 18 Feb 2001 01:19:39 PST." Date: Sun, 18 Feb 2001 11:37:47 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Absolutely, we're in violent agreement on that point. I'm just > suggesting that instead of having the policy be represented by > SUBDIR lines in Makefiles, it should instead be something like > this: > > > > FreeBSD-standard > RELENG_4 > This is what constitutes the "standard" version of FreeBSD > > bin > lib > usr > etc > installer > > OK - this is looking like something that can be played with! I'll take the above example end spend some time seeing if I can come up with some proof-of-concept code. > And when I say something "like" that I'm really reaching because this > is a seriously contrived example which doesn't even begin to enumerate > all the various types of meta-data which one would need to describe > "the standard release of FreeBSD." I'm not even saying it would be in > XML (please put those spears down), only that it would live outside of > the actual build mechanism and simply become configuration data. Right. Personally, i like XML, but the XML support stuff is big, and that scares me. > Such a thing would also finally get rid of all those evil and > not-very-comprehensive NO_FOO variables in the source tree, as if > any of us truly needed to see a list of our current build system's > shortcomings. Right! "Violent agreement", was it? > And yes, I do also realize that coming up with something even half as > sophisticated as what I've described so far will take more than lots > of mere hand-waving on the subject. Progress often moves in strange > ways, so let's just see where all this goes. :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 2:55:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id C301237B4EC for ; Sun, 18 Feb 2001 02:55:39 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1IAt6957670; Sun, 18 Feb 2001 12:55:09 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102181055.f1IAt6957670@gratis.grondar.za> To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Moving Things References: <11284.982487979@winston.osd.bsdi.com> In-Reply-To: <11284.982487979@winston.osd.bsdi.com> ; from Jordan Hubbard "Sun, 18 Feb 2001 01:19:39 PST." Date: Sun, 18 Feb 2001 12:55:43 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Picking up the thread, and renaming it to give a starting point. > > I'd like to point out that making FreeBSD more modular doesn't > > necessarily mean that we have to change the policy we have hard coded > > into the Makefiles. We can and do subset things more easily than > > Absolutely, we're in violent agreement on that point. I'm just > suggesting that instead of having the policy be represented by > SUBDIR lines in Makefiles, it should instead be something like > this: [ example removed ] To properly describe where I am with this now, I ask all of you participants to please stop thinking in terms of individual programs or packages, and take Jordan's 20000 ft view on this. It is plainly obvious that "FreeBSD" means different things to different people. My FreeBSD includes my choice of shell, mailers games X environment and so on. The whole purpose of this discussion is now to find a way of structuring FreeBSD in an extensible way that not only allows people to have what they want, but also to _not_ have what they _don't_ want. Desktop users want lots of X stuff, newsreaders, web browsers, mail clients, flashy screen savers and the like. Server administrators want kick-arse performance in whatever services they offer, and minimal flashiness to slow things down. Turbo-geeks want to configure absolutely everything so that can run FreeBSD in their pocket calculators or wearable computers. Newbies want it to work out-of-the-box, because they don't understand all this configuration crap anyway. Dialup users may have special requirements such as POP services, UUCP, PPP-dial and so on. Security paranoids have a particular list of things-to-remove that is at odds with folks who work behind firewalls. NOBODY wants to be told by some dumb policy decision what he has to have on his machine (if he doesn't want it there). SO - How do we proceed? Here is an idea: PLEASE PLEASE do not look for implementation details in the following; I know it will be hard, but until a decent design comes out, arguing about programming details is futile. Step back and look at FreeBSD as ports and base combined - stir the pot if you will. Imagine a tree (use XML as a sort of concept here, although the final thing could be anything). At the concept level, this is NOT Makefiles, this is a configuration structure. There is a system that understands the above tree, and is able to use it to decide how to install software into the target system. Being a tree, this configuration structure is hierarchical - working from the base will result in more work being done than working from a branch or from a leaf. There would also be dependancies (installing (say) UUCP would depend on installation of any MTA). At the small branch or leaf level, where individual bits are installed, there would be many ways to do things, depending on what you have, and what you want and need. A newbie would install compiled binaries, but a developer would check out sources, and compile/install those. Even developers may not be interested in all sources, and may choose to simply cache or download precompiled sources for things that they use but don't actively work on. All of this should be fluidly configurable. This way, the hardcore types can still to a "make world" (but can choose to leave out junk they don't like) while including in the build their favourite ("portish") tools (editors, servers etc). Comments? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 3:10:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id A507737B503 for ; Sun, 18 Feb 2001 03:10:54 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1IBALH12636; Sun, 18 Feb 2001 03:10:21 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: Moving Things In-Reply-To: Message from Mark Murray of "Sun, 18 Feb 2001 12:55:43 +0200." <200102181055.f1IAt6957670@gratis.grondar.za> Date: Sun, 18 Feb 2001 03:10:21 -0800 Message-ID: <12632.982494621@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Comments? Absolutely! I think I tried to cover too much ground in my initial message(s) and probably wound up with an incomprehensible stream of consciousness as a result, but this states it all very clearly. I'd be very interested in tossing around some possible hierarchies, perhaps offline where they won't clog the mailing list. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 3:17:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 858F537B4EC for ; Sun, 18 Feb 2001 03:17:28 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1IBH7957771; Sun, 18 Feb 2001 13:17:07 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102181117.f1IBH7957771@gratis.grondar.za> To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: Moving Things References: <12632.982494621@winston.osd.bsdi.com> In-Reply-To: <12632.982494621@winston.osd.bsdi.com> ; from Jordan Hubbard "Sun, 18 Feb 2001 03:10:21 PST." Date: Sun, 18 Feb 2001 13:17:44 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Comments? > > Absolutely! > > I think I tried to cover too much ground in my initial message(s) and > probably wound up with an incomprehensible stream of consciousness as > a result, but this states it all very clearly. I'd be very interested > in tossing around some possible hierarchies, perhaps offline where > they won't clog the mailing list. OK! :-) I'd be interested in what you have to say - if you prefer to do it offline, that is cool! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 3:55:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id C925337B491 for ; Sun, 18 Feb 2001 03:55:43 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1IBt7957868; Sun, 18 Feb 2001 13:55:14 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102181155.f1IBt7957868@gratis.grondar.za> To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <3A8E47DC.FAF7F962@elischer.org> In-Reply-To: <3A8E47DC.FAF7F962@elischer.org> ; from Julian Elischer "Sat, 17 Feb 2001 01:43:56 PST." Date: Sun, 18 Feb 2001 13:55:44 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I remember how ill I felt the first time I encountered a Unix system with > no C compiler... The idea here not not "no C Compiler" or in fact "no _anything_". Those are release-engineer policy decisions today, and customer choices tomorrow. _That_ is the point. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 5:30:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 4FA3337B4EC; Sun, 18 Feb 2001 05:30:40 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id A6EC528E9F; Sun, 18 Feb 2001 19:30:31 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 85D6A28E76; Sun, 18 Feb 2001 19:30:31 +0600 (ALMT) Date: Sun, 18 Feb 2001 19:30:28 +0600 (ALMT) From: Boris Popov To: Ian Dowse Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: CFR2: Sequential mbuf read/write extensions In-Reply-To: <200102121409.aa34378@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Well, I've tried to take into account most of the suggestions and placed an updated versions of files to http://www.butya.kz/~bp/mbuf/ If no serious problems will be found I would like to commit this on next week (this version of functions included in the upcoming smbfs-1.3.6). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 9: 0: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 7901F37B4EC for ; Sun, 18 Feb 2001 09:00:05 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UXJt-00009o-00; Sun, 18 Feb 2001 10:08:21 -0700 Message-ID: <3A900185.54C97B10@softweyr.com> Date: Sun, 18 Feb 2001 10:08:21 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <3A8E47DC.FAF7F962@elischer.org> <200102181155.f1IBt7957868@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > > I remember how ill I felt the first time I encountered a Unix system with > > no C compiler... > > The idea here not not "no C Compiler" or in fact "no _anything_". Those > are release-engineer policy decisions today, and customer choices > tomorrow. > > _That_ is the point. Right. For instance, why would you want to cram a C compiler on a flash- based firewall? Or even a disk-based one? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 9: 7:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 2DCE537B401 for ; Sun, 18 Feb 2001 09:07:24 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1IH6h958783; Sun, 18 Feb 2001 19:06:43 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102181706.f1IH6h958783@gratis.grondar.za> To: Wes Peters Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <3A900185.54C97B10@softweyr.com> In-Reply-To: <3A900185.54C97B10@softweyr.com> ; from Wes Peters "Sun, 18 Feb 2001 10:08:21 MST." Date: Sun, 18 Feb 2001 19:07:20 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > _That_ is the point. > > Right. For instance, why would you want to cram a C compiler on a flash- > based firewall? Or even a disk-based one? Zigactly. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 15:28:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iscserv7.nepustil.net (NS.Nepustil.NET [193.96.243.22]) by hub.freebsd.org (Postfix) with ESMTP id 721A437B491 for ; Sun, 18 Feb 2001 15:28:09 -0800 (PST) Received: from peotl.homeip.net (tuebpool-135.pm3.nepustil.net [212.71.200.135]) by iscserv7.nepustil.net (Sendmail) with ESMTP id 02C4579EC7 for ; Mon, 19 Feb 2001 00:28:47 +0100 (CET) Received: (from thz@localhost) by peotl.homeip.net (8.11.1/8.11.1) id f1INMa759622 for freebsd-arch@freebsd.org; Mon, 19 Feb 2001 00:22:36 +0100 (MET) (envelope-from thz) Date: Mon, 19 Feb 2001 00:18:22 +0100 From: Thomas Zenker To: Nate Williams Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010219001822.A58349@peotl.homeip.net> References: <200102161737.f1GHbQ946702@gratis.grondar.za> <14989.27426.877852.291707@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14989.27426.877852.291707@nomad.yogotech.com>; from nate@yogotech.com on Fri, Feb 16, 2001 at 11:02:10AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:02:10AM -0700, Nate Williams wrote: > > > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > > > disappear either. > > > > I'd love to see those go, myself. > > I'd be very angry to see them go. Not every FreeBSD machine is > connected to the internet. R* utilities are very commonly used, and > we're not gaining anything but removing them. > > Disabling them from /etc/inetd.conf is barely acceptable, IMO. > It's ok do disable them in inetd.conf, but to make them dissapear. I myself have to support old firmware in old instruments, the cross compilers are running on old hp300 only... to much trouble to make any changes to the hp. No to disapearance of R* utilities. Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 15:40:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 4E98337B4EC; Sun, 18 Feb 2001 15:40:45 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CB96566B32; Sun, 18 Feb 2001 15:40:43 -0800 (PST) Date: Sun, 18 Feb 2001 15:40:43 -0800 From: Kris Kennaway To: Wes Peters Cc: nbm@freebsd.org, Mark Murray , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010218154043.A37703@mollari.cthul.hu> References: <3A8E47DC.FAF7F962@elischer.org> <200102181155.f1IBt7957868@gratis.grondar.za> <3A900185.54C97B10@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A900185.54C97B10@softweyr.com>; from wes@softweyr.com on Sun, Feb 18, 2001 at 10:08:21AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 18, 2001 at 10:08:21AM -0700, Wes Peters wrote: > Mark Murray wrote: > >=20 > > > I remember how ill I felt the first time I encountered a Unix system = with > > > no C compiler... > >=20 > > The idea here not not "no C Compiler" or in fact "no _anything_". Those > > are release-engineer policy decisions today, and customer choices > > tomorrow. > >=20 > > _That_ is the point. >=20 > Right. For instance, why would you want to cram a C compiler on a flash- > based firewall? Or even a disk-based one? One way to go about this might be to maintain dependency information between various binaries or groups of binaries and enforce this as a graph relationship which provides a consistent system with various features. This ties in with the NetBSD graph-based /etc/rc mechanism which Neil Blaker-Milner has been working on. Neil, what's the status of that anyway? For example, a standalone system which is not internet-connected wouldn't need to install the "network utilities" (telnet, ssh, ftp) or the "network services" (inetd, sshd, ...). It would be tricky (perhaps just time-consuming) to get the dependencies right on the level of individual binaries, but you could imagine the management system allowing selection/deselection of individual elements of a set as well. Kris --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kF17Wry0BWjoQKURAhs/AKCvSZq1nvdawwDkCco23AKov4+nUACePszq JKOQESSpJdbh2Jz8wKMi8cE= =NoTL -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 18:21:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 1713637B491 for ; Sun, 18 Feb 2001 18:21:27 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 56EF21300; Sun, 18 Feb 2001 18:21:26 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id SAA17945; Sun, 18 Feb 2001 18:21:25 -0800 (PST) Message-ID: <3A908324.EF6F4385@cup.hp.com> Date: Sun, 18 Feb 2001 18:21:24 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things References: <11284.982487979@winston.osd.bsdi.com> <200102181055.f1IAt6957670@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > PLEASE PLEASE do not look for implementation details in the following; I > know it will be hard, but until a decent design comes out, arguing about > programming details is futile. I'm going to play devil's advocate now. Mostly because I'm cynical WRT this, but also because it allows us all (yes, that includes me) to verify our views and/or give us (again, "moi aussi") a chance to set our minds straight.... I claim that what we're discussing is implementation by definition: (taking a good dose of that ol' Janx Spirit) Back to the original question: "should games stay or should it go?". This question can also be asked like: "Sendmail or postfix?". It's a question about preferences and pre-selections and thus policies and/or philosophies. If we let go of the answers and implement a framework that allows everybody to answer that question for his or herself, then how do we define FreeBSD? For example: The question "Did you test your changes with a make world?" would be completely meaningless. World for that matter could be anything. Currently world is defined by what we consider FreeBSD to be, or put differently: the implementation of what FreeBSD is, defines what world is. If we have a policy-free framework then to be able to validate a change, we have to define a "configuration" that is considered "minimal" in the sense that any change should leave that configuration unbroken. Consequently, this consiguration will result in the same preferences and pre-selections as we currently have in our source tree and by definition will define what FreeBSD is. The problem of what to keep or remove from a configuration is exactly the same as the problem we're discussing now: what to keep or remove from the source tree. Since we didn't change or solve the problem, the only thing we must have changed is the implementation! (taking another dose of that "good ol' Janx Spirit" --- I'm getting even more vague now :-) What makes us different from NetBSD and OpenBSD (for example) is first of all our philosophy, not so much our implementation. It's our philosophy that gives shape to our implementation and it's our philosophy that defines what we consider important. If we manage to come up with an objective and policy-free framework then, consequently, we should be able to implement NetBSD and OpenBSD with it, right? The initial issue of whether or not we should remove games is not so much an attempt to change an implementation, it's more a change in policy/philosophy. The immediate discussion that followed (ie: UUCP should go as well; remove the r* tools) is also policy/philosophy. It's an attempt to change what FreeBSD is considered to be and what we think is important. Our current implementation encodes this policy and philosophy. The idea to remove the wall between ports and source tree is an approach to overcome that limitation: it addresses the implementation. Not looking at implementations is therefore impossible... (sobering up...) In general I think that flexibility is good. But there's also such a thing as too much flexibility, because with flexibility comes complexity. Not only implementation complexity, but also comprehension complexity. I think we should allow people to install postfix(1) without having to install sendmail(1). We should allow gcc(1) to be replaced by a compiler that produces better code on certain platforms. However, I don't think there's much value in being able to *not* install sleep(1), only because the maintainer doesn't get any himself. I fear that a framework that allows that level of freedom will simply not work, because the meta-information involved to guarantee a consistent "configuration" or a stable system (as it is installed) will require more work to maintain than what would have been needed for the actual sources in a more resticted framework; hence the lack of sleep :-) I also fear that any attempt to design such a policy-free framework will end up in the same situation as sysinstall/NG: it's always coming, but it never arrives. The reason being that there are so many solutions and they're all flawed... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 18:46:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 14CFD37B4EC for ; Sun, 18 Feb 2001 18:44:10 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Ue5L-0000HQ-00; Sun, 18 Feb 2001 17:21:47 -0700 Message-ID: <3A90671B.AEE88134@softweyr.com> Date: Sun, 18 Feb 2001 17:21:47 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things References: <11284.982487979@winston.osd.bsdi.com> <200102181055.f1IAt6957670@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > Step back and look at FreeBSD as ports and base combined - stir the pot > if you will. Imagine a tree (use XML as a sort of concept here, although > the final thing could be anything). At the concept level, this is NOT > Makefiles, this is a configuration structure. > > There is a system that understands the above tree, and is able to use it > to decide how to install software into the target system. > > Being a tree, this configuration structure is hierarchical - working > from the base will result in more work being done than working from a > branch or from a leaf. There would also be dependancies (installing > (say) UUCP would depend on installation of any MTA). I've been doing exactly this at work the past couple of weeks, and so will share what we've come up with so far. I'll also point out the weaknesses we see, and you all can point out the ones we haven't seen yet. ;^) We started out in mid-December to build a few optional packages; things our customers could buy and install after they have a DoBox in their home. Some of our OEM customers may wish to pre-install some of these packages, so we had to address the issue of making a package that could be installed either on a running system (the way packages currently are) or on a development system, installing into a DESTDIR. Our system is in many way simpler than a generic FreeBSD installation, and more complex in a few significant ways as well. Our configuration data is stored in a database -- PostgreSQL currently -- which does not lend itself to simply appending configuration data to a file somewhere. All of our daemons processes are started via shell script in an rc.d directory. We have extended these shells scripts to accept several more "reason" arguments than the standard "start" and "stop." One new reason is "init", which means this machine is in a "first birthday" boot, where database tables may be added and populated, etc. The end-user will never see this first birthday boot, it happens in the factory during the factory acceptance test. This allows us to use the post-install script to prime the database on a running system, or the rc.d script to do so if the package is "factory installed". We are currently defining the "release" process, which builds a system image in a destination directory. What we have discussed so far is a list of all the optional packages to install; the release process will copy the "base system" into the destination, then install each of the packages one by one. Note: some of these packages are trivial, involving a few web pages for the UI, others are quite complex. The one I just completed is a complete mailserver, involving an MTA, POP/IMAP server, fetchmail, and some custom glue to tie all of the above into our configuration database.* One we defined this mechanism, we realized that much of what we consider to be a "standard" part of our system could easily be extracted out this way, making it simpler to offer our system to OEMs ala carte. We are in the process of converting everything but the base OS to this framework now. Exactly what the "base OS" is is being re-defined on a daily basis, too. So far, this system is working fairly well, though we keep finding little bits that we have to re-address as we contemplate installing various facilities both at system build time and on a running system. I'm sure we'll run into some interesting conundrums as we confront upgrading components in the field as well. > At the small branch or leaf level, where individual bits are installed, > there would be many ways to do things, depending on what you have, and > what you want and need. A newbie would install compiled binaries, but > a developer would check out sources, and compile/install those. Even > developers may not be interested in all sources, and may choose to > simply cache or download precompiled sources for things that they use > but don't actively work on. All of this should be fluidly configurable. > > This way, the hardcore types can still to a "make world" (but can choose > to leave out junk they don't like) while including in the build their > favourite ("portish") tools (editors, servers etc). In our system, "make world" builds everything, it is the release process that selects one part or another. This would probably not be effective for FreeBSD; we don't necessarily want to populate the source for every package in the ports tree just to build the kernel. * This one has to remain an end-user chosen option, due to the GPL on the fetchmail code. If anyone knows of a fetchmail-like program under a more usable license, I'd love to hear about it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 18:46:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 1573B37B4EC; Sun, 18 Feb 2001 18:46:43 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UeMa-0000Hw-00; Sun, 18 Feb 2001 17:39:36 -0700 Message-ID: <3A906B48.CA282D89@softweyr.com> Date: Sun, 18 Feb 2001 17:39:36 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: nbm@freebsd.org, Mark Murray , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <3A8E47DC.FAF7F962@elischer.org> <200102181155.f1IBt7957868@gratis.grondar.za> <3A900185.54C97B10@softweyr.com> <20010218154043.A37703@mollari.cthul.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > One way to go about this might be to maintain dependency information > between various binaries or groups of binaries and enforce this as a > graph relationship which provides a consistent system with various > features. This ties in with the NetBSD graph-based /etc/rc mechanism > which Neil Blaker-Milner has been working on. Neil, what's the status > of that anyway? Interesting. This was discussed to death and then dropped a couple of years ago, but I see a lot of promise there. Finding a simple way to describe the dependencies such that they can be processed with a tool seems to be the only real hurdle to having such an rc mechanism. > For example, a standalone system which is not internet-connected > wouldn't need to install the "network utilities" (telnet, ssh, ftp) or > the "network services" (inetd, sshd, ...). It would be tricky > (perhaps just time-consuming) to get the dependencies right on the > level of individual binaries, but you could imagine the management > system allowing selection/deselection of individual elements of a set > as well. Another advantage is that we can build "system profiles" into the release and installation tools. Non-system programmers could easily contribute to these system profiles by building the system of their dreams then taking a snapshot of what they have installed on the system. We could drop these into various categories and offer them as advanced install options. I envision profiles like: Workstations Standard workstation in flavors: Gnome/Enlightenment KDE WindowMaker + WDM + DockApps + whatever Small workstation (i.e. laptop) FreeBSD development workstation (sources for everything) Graphics workstation Secure workstation High-function workstation (everything in x11*) Mail Servers Standard mail server (sendmail, uw-imap, net tools?) Secure mail server (postfix, cyrus, ssh only?) Multiple-domain virtual mail server and so on. Just think, we could even get Brett Glass to contribute his own profiles, and he would be able to have the Brett Glass installation he's always wanted, but we've never been able to deliver. (This is NOT a slap at Brett, but rather recognition that with some added flexibility in the build and install tools, we could provide what he has often asked for.) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 19:56:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 8A0C437B491 for ; Sun, 18 Feb 2001 19:56:13 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1J3mnH15431; Sun, 18 Feb 2001 19:48:50 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Marcel Moolenaar Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things In-Reply-To: Message from Marcel Moolenaar of "Sun, 18 Feb 2001 18:21:24 PST." <3A908324.EF6F4385@cup.hp.com> Date: Sun, 18 Feb 2001 19:48:49 -0800 Message-ID: <15427.982554529@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Back to the original question: "should games stay or should it go?". > This question can also be asked like: "Sendmail or postfix?". It's a > question about preferences and pre-selections and thus policies and/or > philosophies. If we let go of the answers and implement a framework that > allows everybody to answer that question for his or herself, then how do > we define FreeBSD? I think the point has already been made more than once that how we "define FreeBSD" need be no less stringent and carved-in-stone than it is now. Sure, a redesigned mechanism might more easily allow people to walk off the beaten path, but that doesn't mean we won't still furnish a very clear "approved path" and make it equally clear that people walking elsewhere do so at their own risk. > For example: The question "Did you test your changes with a make world?" > would be completely meaningless. Not at all. It just becomes true that "make world" only has meaning for those tracking one of the standard configuration sets, just as it currently holds meaning only for those who don't manually hack their /usr/src trees before making the world. More flexible mechanisms don't automatically imply that policy is sacrificed as a side-effect. Actually, if one looks to the real world for examples, it would appear that policies actually become even more strict and well-defined as the mechanisms become more flexible. They have to. In systems like ours, on the other hand, where much of the policy is enforced through accidental or deliberate limitations in the mechanism, nobody feels any particular compulsion to document policies which are largely hard-coded. I therefore can't really see a supporting argument for lumping policy and mechanism together from *either* side of the coin. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 20: 7: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 78FB437B401 for ; Sun, 18 Feb 2001 20:07:01 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id VAA26662; Sun, 18 Feb 2001 21:00:50 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAXfaa6Z; Sun Feb 18 21:00:34 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA11061; Sun, 18 Feb 2001 21:06:40 -0700 (MST) From: Terry Lambert Message-Id: <200102190406.VAA11061@usr05.primenet.com> Subject: Re: Moving Things [was Re: List of things to move from main tree] To: mark@grondar.za (Mark Murray) Date: Mon, 19 Feb 2001 04:06:34 +0000 (GMT) Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <200102180937.f1I9b9957438@gratis.grondar.za> from "Mark Murray" at Feb 18, 2001 11:37:47 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Right. Personally, i like XML, but the XML support stuff is big, > and that scares me. The Xerces source code is 5 1/2 MB, compressed. I don't know how big the Gnome library is, or how big the Xerces shared library is, once it's compiled. If XML is going to be used during install, maybe it'd be a good idea to build a small LALR parser, which only knows about the grammar to be used for the specific application. If it's just going to be used for the build of the packages tehmselves, then it'd be OK to have a large, hulking thing as part of that process. Really, FreeBSD is limited by the low end installation media, but I can't see getting rid of that as being positive; I've brought up too may BSD boxes from floppies. I think that whatever gets done, people have to accept that there are some basic constraints on some of this stuff, having to do with the source repository layout. For example, I think it would be a bad idea to move the games around in the repository, just because people want them to be ports, instead of installed by default. It makes no sense to do that. I also think that a nice first run at lists of files installed would be a good thing; frankly, it's very hard to relocate most net software, to know where and what was installed, and to then build something that expects to be installed in a particular location, make an image, and then do the install later. Shared libraries are a particular problem, in that regard. The best way I've thought of to address that so far is to hack make to log calls to "install", "mv", and "cp", when their target isn't interior to the build hierarchy. The utility being built would be logged, along with what got installed as part of the build. Not perfect, but then you at least know what files ended up where as a result of a "make install" for any given utility. Thinking more on this, I think that make should probably scream about the use of "mv" and "cp" instead of "install", so that they can be replaced with "install". Then you could log with install along, just by adding an option that let you add the name of the thing to the log file, as another argument. 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 20:25:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id C27B737B4EC for ; Sun, 18 Feb 2001 20:25:55 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id VAA72240 for ; Sun, 18 Feb 2001 21:25:27 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdl0iBqa; Sun Feb 18 21:25:21 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA11378 for arch@freebsd.org; Sun, 18 Feb 2001 21:25:48 -0700 (MST) From: Terry Lambert Message-Id: <200102190425.VAA11378@usr05.primenet.com> Subject: Re: Moving Things To: arch@freebsd.org Date: Mon, 19 Feb 2001 04:25:42 +0000 (GMT) In-Reply-To: <200102181055.f1IAt6957670@gratis.grondar.za> from "Mark Murray" at Feb 18, 2001 12:55:43 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To add some more fuel to the fire, here is the source code for the SCO configuration management tools: http://www.sco.com/skunkware/devtools/#mkvol http://www.sco.com/skunkware/devtools/#mkpkg http://www.sco.com/skunkware/devtools/#pkgtools PS: I'm still thinking that an "installshield" type tool, and a Windows-like "Add/Remove Programs" control panel would be a healthy chunk of having all this work done. PPS: There's a Java version of InstallShield, which can run on FreeBSD: http://www.installshield.com/iemp/features/default.asp 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 20:27:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id BEE4437B503 for ; Sun, 18 Feb 2001 20:27:41 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id VAA09545; Sun, 18 Feb 2001 21:22:41 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA7QaWKs; Sun Feb 18 21:22:31 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA11418; Sun, 18 Feb 2001 21:27:29 -0700 (MST) From: Terry Lambert Message-Id: <200102190427.VAA11418@usr05.primenet.com> Subject: Re: Moving Things To: mark@grondar.za (Mark Murray) Date: Mon, 19 Feb 2001 04:27:24 +0000 (GMT) Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <200102181117.f1IBH7957771@gratis.grondar.za> from "Mark Murray" at Feb 18, 2001 01:17:44 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think I tried to cover too much ground in my initial message(s) and > > probably wound up with an incomprehensible stream of consciousness as > > a result, but this states it all very clearly. I'd be very interested > > in tossing around some possible hierarchies, perhaps offline where > > they won't clog the mailing list. > > OK! :-) > > I'd be interested in what you have to say - if you prefer to do it > offline, that is cool! Perhaps configuration management deserves its own list? How about config-freebsd, anyone? 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 20:55: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 163C837B401 for ; Sun, 18 Feb 2001 20:54:59 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UiVa-0000NI-00; Sun, 18 Feb 2001 22:05:10 -0700 Message-ID: <3A90A986.C8455C8A@softweyr.com> Date: Sun, 18 Feb 2001 22:05:10 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Moving Things References: <200102190425.VAA11378@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > To add some more fuel to the fire, here is the source code for the > SCO configuration management tools: > > http://www.sco.com/skunkware/devtools/#mkvol > http://www.sco.com/skunkware/devtools/#mkpkg > http://www.sco.com/skunkware/devtools/#pkgtools > > PS: I'm still thinking that an "installshield" type tool, and a > Windows-like "Add/Remove Programs" control panel would be a > healthy chunk of having all this work done. > > PPS: There's a Java version of InstallShield, which can run on > FreeBSD: http://www.installshield.com/iemp/features/default.asp At Clyde Digital/Raxco/Axent Technologies, we did a platform-independant installer that was a shell script with a .tgz appended to it. The script determined which platform it was running on and extracted the correct bits for that architecture and operating system. Before anyone gets their undies in a bundle over this, it might be worth- while to coordinate with the Open Packages folks, who seem to be working on similar issues. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21: 2:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1866737B401 for ; Sun, 18 Feb 2001 21:02:10 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id VAA14917; Sun, 18 Feb 2001 21:56:00 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAv_aybD; Sun Feb 18 21:55:52 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA12085; Sun, 18 Feb 2001 22:01:56 -0700 (MST) From: Terry Lambert Message-Id: <200102190501.WAA12085@usr05.primenet.com> Subject: Re: Moving Things To: marcel@cup.hp.com (Marcel Moolenaar) Date: Mon, 19 Feb 2001 05:01:55 +0000 (GMT) Cc: mark@grondar.za (Mark Murray), jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <3A908324.EF6F4385@cup.hp.com> from "Marcel Moolenaar" at Feb 18, 2001 06:21:24 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (taking a good dose of that ol' Janx Spirit) > > Back to the original question: "should games stay or should it go?". > This question can also be asked like: "Sendmail or postfix?". It's a > question about preferences and pre-selections and thus policies and/or > philosophies. If we let go of the answers and implement a framework that > allows everybody to answer that question for his or herself, then how do > we define FreeBSD? Whatever "Janx Spirit" is, spit it out. Windows practically lets you add or remove much of the OS, starting with a number of broad categories, and then having a "details" button that further breaks these categories down, and elect to add or remove individual subcomponents. No one calls it "not Windows" because every optional thing that can be removed has been removed (If you open up the control panel, and go to Accessoris/Screen Savers/Flying Windows, and uncheck the box to remove that one file, it's still Windows). There's undeniably merit in knowing, without having to go looking, that an installation of your OS will come with some things, by default. I think that having "preferred" sets for various purposes, including "Minimal" and "Maximal" installations, or "server" and "workstation" and "laptop" and "8M flash" and "firewall", etc., configurations, which can then be further customized (perhaps to the point of taking the defaults for a server, and turning it into a setup identical to what you would have gotten, had you chosen "laptop"), is definitely the direction everyone should be thinking. So if you are worrying over becoming something other than FreeBSD merely by having a more, you can definitely stop panicing; if it were that easy, I would have long ago removed the file from my Windows box that made it be "Windows". 8-). I'm finding much sympathy with the Linux camp's assertion that Linux is the kernel, and everything else is just a distribution... 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21: 5:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id E379537B491 for ; Sun, 18 Feb 2001 21:03:14 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UicM-0000Na-00; Sun, 18 Feb 2001 22:12:10 -0700 Message-ID: <3A90AB2A.E2C4F64@softweyr.com> Date: Sun, 18 Feb 2001 22:12:10 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Mark Murray , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <200102190406.VAA11061@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > Right. Personally, i like XML, but the XML support stuff is big, > > and that scares me. > > The Xerces source code is 5 1/2 MB, compressed. I don't know how > big the Gnome library is, or how big the Xerces shared library is, > once it's compiled. > > If XML is going to be used during install, maybe it'd be a good > idea to build a small LALR parser, which only knows about the > grammar to be used for the specific application. Expat helps build such parsers. The syntax is slightly weird, but it's a lot smaller than 5.5 MB. > I think that whatever gets done, people have to accept that there > are some basic constraints on some of this stuff, having to do > with the source repository layout. > > For example, I think it would be a bad idea to move the games > around in the repository, just because people want them to be > ports, instead of installed by default. It makes no sense to do > that. I think the idea is push everything that cannot be considered a core part of the operating system into a different part of the tree, that can be chosen from ala carte. This is a lot more extensive than moving games to the ports tree. Telnet, ftp, rtools, UUCP, sendmail, DNS, etc. > I also think that a nice first run at lists of files installed > would be a good thing; frankly, it's very hard to relocate most > net software, to know where and what was installed, and to then > build something that expects to be installed in a particular > location, make an image, and then do the install later. Shared > libraries are a particular problem, in that regard. The package dependency mechansim helps take care of that. If you select a package that requires a shared library you don't have, the dependency will install the shared library package as well. > The best way I've thought of to address that so far is to hack > make to log calls to "install", "mv", and "cp", when their > target isn't interior to the build hierarchy. The utility being > built would be logged, along with what got installed as part of > the build. Not perfect, but then you at least know what files > ended up where as a result of a "make install" for any given > utility. > > Thinking more on this, I think that make should probably scream > about the use of "mv" and "cp" instead of "install", so that they > can be replaced with "install". Then you could log with install > along, just by adding an option that let you add the name of the > thing to the log file, as another argument. In that case, we should add an option to install to perform links and symlinks, and have make scream about "ln" as well. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21:15:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 2D07137B401 for ; Sun, 18 Feb 2001 21:15:44 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id WAA34076; Sun, 18 Feb 2001 22:15:15 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdkkn3Ea; Sun Feb 18 22:15:10 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA12356; Sun, 18 Feb 2001 22:15:36 -0700 (MST) From: Terry Lambert Message-Id: <200102190515.WAA12356@usr05.primenet.com> Subject: Re: Moving Things [was Re: List of things to move from main tree] To: wes@softweyr.com (Wes Peters) Date: Mon, 19 Feb 2001 05:15:36 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), mark@grondar.za (Mark Murray), jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <3A90AB2A.E2C4F64@softweyr.com> from "Wes Peters" at Feb 18, 2001 10:12:10 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If XML is going to be used during install, maybe it'd be a good > > idea to build a small LALR parser, which only knows about the > > grammar to be used for the specific application. > > Expat helps build such parsers. The syntax is slightly weird, but it's > a lot smaller than 5.5 MB. Writing a parser is trivial, even if you don't use lex/yacc or some other tool to do it. It's not really as interesting to talk about the implementation details as it is to know that a pure XML parser bent into an install tool is probably way too large for a floppy. > I think the idea is push everything that cannot be considered a core > part of the operating system into a different part of the tree, that > can be chosen from ala carte. This is a lot more extensive than > moving games to the ports tree. Telnet, ftp, rtools, UUCP, sendmail, > DNS, etc. That's fine, but we don't need to move it around in the repository, lose its history, and add gigabytes to the attic. > > I also think that a nice first run at lists of files installed > > would be a good thing; frankly, it's very hard to relocate most > > net software, to know where and what was installed, and to then > > build something that expects to be installed in a particular > > location, make an image, and then do the install later. Shared > > libraries are a particular problem, in that regard. > > The package dependency mechansim helps take care of that. If you > select a package that requires a shared library you don't have, the > dependency will install the shared library package as well. The problem is more that, once something is linked against a shared library, moving the library around is not really an option. Speaking of which, is anyone else incredibly annoyed that ld.so doesn't search for things not in the ldconfig cache? My personal experience is similar to what you said your company had been doing for builds. I have a 6-pass build process that builds a lot of open source stuff, and a lot of my own stuff, and then builds distribution packages out of it. There is a seperate package for each server role. Obviously, you could install all the distributions onto a single box (makes a good demo system, except you can't demostrate data replication), but typically you would set up a data center so that you had each role on a seperate machine, and two or more machines for each role. The point of this is that it's much more logical to think of configuration management in terms of the roles you expect a machine to take, and that, at least for users, the important thing is to be able to choose binary sets to install (or not), cafeteria style. That may mean you can't get a ham sandwich without also getting mustard, unless you pick the "custom" option, and dick with the details. Having a template works best (e.g. "Ham sandwitch without mustard" is better than "bread, ham, lettuce, swiss cheese, mayonaise, tomato"). 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21:45:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 2907B37B65D for ; Sun, 18 Feb 2001 21:45:27 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id WAA38198; Sun, 18 Feb 2001 22:44:59 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdQkD3ya; Sun Feb 18 22:44:58 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA12821; Sun, 18 Feb 2001 22:45:25 -0700 (MST) From: Terry Lambert Message-Id: <200102190545.WAA12821@usr05.primenet.com> Subject: Dialer interface To: josb@cncdsl.com Date: Mon, 19 Feb 2001 05:45:25 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010217162656.E54688@lizzy.bugworks.com> from "Jos Backus" at Feb 17, 2001 04:26:56 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Yes, the 'dialer' interface is a bit of a mess. Several years ago > > there was an entry in the CSRG project wish list for a networked > > dialer daemon that would intermediate access to dialout tty devices. > > (I *think* it was Keith Bostic's idea.) This might solve part of > > the problem. > > Maybe we could import BSD/OS' gettyd. Please don't. Microport had a much better approach in the mid 1908's, where you have three devices, /dev/tty11, /dev/tty11m, /dec/tty11M. One device had no modem control; this effectively meant that it didn't require DCD to open, or use CTS/RTS handshaking, or assert DTR only when an open was pending (so that a modem would answer the phone). I think modem control bit can be managed (or should be) via the gettytab, today. There were also two modem control devices: one for inbound calls, and one for outbound calls. The getty sat in the open on the inbound one, waiting for DCD to go high. When DCD went high, the open completed, and it spit out /etc/issue and it's initial "login: " request (getty issued this, so that you could still send it break, and get it to do the baud rate rotor thing; this predated baud rate locking in modems, but would be valid today with older modems to supporting locking, and/or people who hate having screens of data flash past after they hit ^C). If the outbound device was open, then the inbound open would be blocked, regardless of where or not DCD was present. That way you could call out on the outbound device, have DCD go high when the connection came up, and not be fighting with getty. The outbound device did not block its open pending DCD. If the inbound device was active because of the DCD being high from an incoming call being there first, then the open of the outgoing device would be failed (instead of blocking). So basically, getty ran all the time, not like the "enable/disable" thing on SCO, and not like the getty whose open completed, that then looked for a lock file, and closed and backed off until, as it checked once a minute, the lock file went away. This is, I think, how it should work. Only today, we could use only two devices, since modem controls could be handled in the gettytab, letting us get rid of the non-modem-control device (getty would open with O_NDELAY on such devices). For dealing with FAX, VOICE, and DATA calls, seperately, based on the connection notification banner from the modem, another O_RING (I don't care what it's named) option to open could let the open complete when RI went high, instead of waiting for DCD to be asserted (and missing the banner). A lot of the multiplex getty replacements open O_NDELAY and then watch for the banner. This conflicts with the ability to dial out on the same device. The O_RING approach resolves this problem (assuming there is no connection, the getty can close and reopen to wait for the next call, at the same time getting out of the way of a dialout). PS: I wrote a networked dialer daemon in the late 1980's, at Century Software. I don't think Greg ever released it as a prouct; he might be willing to give out the code. If not, it's a really, really trivial thing to write (the one I did used telnet protocol over the wire, and lived on a seperate port). 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5BE9937B69E for ; Sun, 18 Feb 2001 21:43:54 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Uj8f-0000PP-00; Sun, 18 Feb 2001 22:45:33 -0700 Message-ID: <3A90B2FD.68EDC2E1@softweyr.com> Date: Sun, 18 Feb 2001 22:45:33 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <200102190515.WAA12356@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > If XML is going to be used during install, maybe it'd be a good > > > idea to build a small LALR parser, which only knows about the > > > grammar to be used for the specific application. > > > > Expat helps build such parsers. The syntax is slightly weird, but it's > > a lot smaller than 5.5 MB. > > Writing a parser is trivial, even if you don't use lex/yacc or some > other tool to do it. It's not really as interesting to talk about > the implementation details as it is to know that a pure XML parser > bent into an install tool is probably way too large for a floppy. Uh, yeah. There is the added benefit that I can provide source to several fairly simple parsers written with Expat, and the license is reasonable. > > I think the idea is push everything that cannot be considered a core > > part of the operating system into a different part of the tree, that > > can be chosen from ala carte. This is a lot more extensive than > > moving games to the ports tree. Telnet, ftp, rtools, UUCP, sendmail, > > DNS, etc. > > That's fine, but we don't need to move it around in the repository, > lose its history, and add gigabytes to the attic. I'm less concerned with disk space on the CVS server (and backups) than I am with modularizing the build system. > > The package dependency mechansim helps take care of that. If you > > select a package that requires a shared library you don't have, the > > dependency will install the shared library package as well. > > The problem is more that, once something is linked against a > shared library, moving the library around is not really an > option. Nor should it be necessary. Each library has one and only one home; if we want to define "/usr/lib" as "the place where the libraries shipped with the base system are found" and "/usr//lib" as "the place where all libraries installed from packages are found", I don't see any issue other than making sure "/usr//lib" is in ld.so's path. I refuse to participate in discussions of the value of because it just doesn't matter. > Speaking of which, is anyone else incredibly annoyed > that ld.so doesn't search for things not in the ldconfig cache? Yes. > My personal experience is similar to what you said your company > had been doing for builds. I have a 6-pass build process that > builds a lot of open source stuff, and a lot of my own stuff, > and then builds distribution packages out of it. There is a > seperate package for each server role. Obviously, you could > install all the distributions onto a single box (makes a good > demo system, except you can't demostrate data replication), but > typically you would set up a data center so that you had each > role on a seperate machine, and two or more machines for each > role. Yup. Let me know if you want some pointers on low-cost small computers for demo machines. > The point of this is that it's much more logical to think of > configuration management in terms of the roles you expect a > machine to take, and that, at least for users, the important > thing is to be able to choose binary sets to install (or not), > cafeteria style. That may mean you can't get a ham sandwich > without also getting mustard, unless you pick the "custom" > option, and dick with the details. Having a template works > best (e.g. "Ham sandwitch without mustard" is better than > "bread, ham, lettuce, swiss cheese, mayonaise, tomato"). Right. A design goal should be to make it relatively simple to let skilled system administrators put together their own definitions, and some way to add these definitions into an install medium. Collecting a large set of these and adding them to the base install seems like a good idea, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 21:47:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 43B1C37B491 for ; Sun, 18 Feb 2001 21:47:29 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id WAA76654; Sun, 18 Feb 2001 22:47:00 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdKtHjMa; Sun Feb 18 22:46:57 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA12829; Sun, 18 Feb 2001 22:47:24 -0700 (MST) From: Terry Lambert Message-Id: <200102190547.WAA12829@usr05.primenet.com> Subject: DJBDNS vs. BIND To: josb@cncdsl.com Date: Mon, 19 Feb 2001 05:47:24 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010217161833.D54688@lizzy.bugworks.com> from "Jos Backus" at Feb 17, 2001 04:18:33 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Please don't. DJBDNS lacks significant and important functionality > > for all but trivial (one controller or single zone) uses. > > Maybe you should tell Dan what functionality you think is missing, and see > what he says. There are very good reasons behind djbdns's current feature set. I think the license is a show stopper, anyway. Somwthing so basic has got to be locally hackable, and the hacked code has got to be distributable. 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-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 22: 2:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 03F7B37B503 for ; Sun, 18 Feb 2001 22:02:28 -0800 (PST) Received: (qmail 20277 invoked by uid 1000); 19 Feb 2001 06:02:49 -0000 Date: Sun, 18 Feb 2001 22:02:27 -0800 From: Jos Backus To: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010218220227.H28286@lizzy.bugworks.com> Reply-To: Jos Backus References: <20010217161833.D54688@lizzy.bugworks.com> <200102190547.WAA12829@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102190547.WAA12829@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 19, 2001 at 05:47:02AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 05:47:02AM +0000, Terry Lambert wrote: > I think the license is a show stopper, anyway. Somwthing so basic > has got to be locally hackable, What kind of hacking do you foresee? We could always ask Dan to do the hacking, see how he feels about that. > and the hacked code has got to be distributable. Dan also wants to see more widespread use of his software - maybe a middle ground can be found. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 22:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 6185337B503 for ; Sun, 18 Feb 2001 22:47:10 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id D138D71; Sun, 18 Feb 2001 22:47:09 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id WAA22277; Sun, 18 Feb 2001 22:47:04 -0800 (PST) Message-ID: <3A90C167.5AED22D4@cup.hp.com> Date: Sun, 18 Feb 2001 22:47:03 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Mark Murray , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things References: <200102190501.WAA12085@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Windows practically lets you add or remove much of the OS, starting > with a number of broad categories, and then having a "details" button > that further breaks these categories down, and elect to add or remove > individual subcomponents. This is all in the realm of the user. The discussion is about the realm of the developer. The installation process is a mere byproduct of what is being discussed now. > There's undeniably merit in knowing, without having to go looking, > that an installation of your OS will come with some things, by > default. Agreed. > I'm finding much sympathy with the Linux camp's assertion that > Linux is the kernel, and everything else is just a distribution... They have my sympathy as well :-) -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:16:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5384A37B65D for ; Sun, 18 Feb 2001 23:16:05 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Uki4-0000SJ-00; Mon, 19 Feb 2001 00:26:13 -0700 Message-ID: <3A90CA94.D7CBCB65@softweyr.com> Date: Mon, 19 Feb 2001 00:26:12 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > Please don't. DJBDNS lacks significant and important functionality > > > for all but trivial (one controller or single zone) uses. > > > > Maybe you should tell Dan what functionality you think is missing, and see > > what he says. There are very good reasons behind djbdns's current feature set. > > I think the license is a show stopper, anyway. Somwthing so basic > has got to be locally hackable, and the hacked code has got to be > distributable. Some of the assumptions behind the operation of djbdns may not hold true for your installation. That, along with the unmaintainability of the software fails to convince me it is a viable replacement for BIND. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:22:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id E0B3E37B67D for ; Sun, 18 Feb 2001 23:22:04 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1J7M0r54717; Sun, 18 Feb 2001 23:22:00 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102190722.f1J7M0r54717@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jos Backus Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND In-Reply-To: <20010218220227.H28286@lizzy.bugworks.com> Date: Sun, 18 Feb 2001 23:22:00 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jos Backus wrote: > On Mon, Feb 19, 2001 at 05:47:02AM +0000, Terry Lambert wrote: > > I think the license is a show stopper, anyway. Somwthing so basic > > has got to be locally hackable, > > What kind of hacking do you foresee? It does not matter. The fact that we cannot is a show stopper. We do not have read-only source in our tree, period. If we ever did need to (eg: a compile problem), we could not distribute it. Even the djbdns port is marked FORBIDDEN because of this as it has two tiny patches. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:39:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 8360F37B401 for ; Sun, 18 Feb 2001 23:39:17 -0800 (PST) Received: (qmail 1593 invoked by uid 1000); 19 Feb 2001 07:39:38 -0000 Date: Sun, 18 Feb 2001 23:39:16 -0800 From: Jos Backus To: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010218233916.J28286@lizzy.bugworks.com> Reply-To: Jos Backus References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A90CA94.D7CBCB65@softweyr.com>; from wes@softweyr.com on Mon, Feb 19, 2001 at 12:25:50AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is rapidly turning into a bikeshed...] On Mon, Feb 19, 2001 at 12:25:50AM -0700, Wes Peters wrote: > Some of the assumptions behind the operation of djbdns may not hold true > for your installation. Some of those behind BIND's operation may not either. BIND's instability and problems are costing people and companies all over the world real time and money. > That, along with the unmaintainability of the software fails to convince me > it is a viable replacement for BIND. Again, what's there to maintain? Fix bugs/security problems? -= * =- I can't help getting the impression that people don't care to give djbdns a proper look because of the way they perceive its author. Who cares what kind of personality the author has, as long as the code works and is well-supported? -- Jos Backus _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:42:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 3BB5E37B401 for ; Sun, 18 Feb 2001 23:42:51 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1J7gEH16124; Sun, 18 Feb 2001 23:42:15 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Terry Lambert Cc: mark@grondar.za (Mark Murray), arch@FreeBSD.ORG Subject: Re: Moving Things In-Reply-To: Message from Terry Lambert of "Mon, 19 Feb 2001 04:27:24 GMT." <200102190427.VAA11418@usr05.primenet.com> Date: Sun, 18 Feb 2001 23:42:14 -0800 Message-ID: <16120.982568534@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps configuration management deserves its own list? Indeed! freebsd-config has been around since January of 1998 and has some 225 people and lists subscribed to it. I would definitely urge anyone interested in further discussion on this topic to join that list if they haven't already. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:50:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 8487A37B503 for ; Sun, 18 Feb 2001 23:50:32 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1J7oOe95300; Sun, 18 Feb 2001 23:50:24 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Feb 2001 23:50:24 -0800 From: "David O'Brien" To: Jos Backus Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010218235023.A95040@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010218233916.J28286@lizzy.bugworks.com>; from josb@cncdsl.com on Sun, Feb 18, 2001 at 11:39:16PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 18, 2001 at 11:39:16PM -0800, Jos Backus wrote: > [This is rapidly turning into a bikeshed...] Bullcrap. You are *totally* missing the point. > Again, what's there to maintain? Fix bugs/security problems? Do you not understand the BSD philosophy??? Core code in BSD *must* be hackable by users for *any* reason they care to. If I want to take all the error messages, process them thru `jive' and recompile djbdns with those, I *MUST* be legally able to do so. > I can't help getting the impression that people don't care to give djbdns a > proper look because of the way they perceive its author. Who cares what kind > of personality the author has, as long as the code works and is > well-supported? WE care if it has a license against the BSD philosophy. Period. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 18 23:57:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 8959537B401 for ; Sun, 18 Feb 2001 23:57:49 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 11E9E4B4; Sun, 18 Feb 2001 23:57:49 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id XAA23489; Sun, 18 Feb 2001 23:57:47 -0800 (PST) Message-ID: <3A90D1FB.D02C2931@cup.hp.com> Date: Sun, 18 Feb 2001 23:57:47 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things References: <15427.982554529@winston.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > > I think the point has already been made more than once that how we > "define FreeBSD" need be no less stringent and carved-in-stone than it > is now. Sure, a redesigned mechanism might more easily allow people > to walk off the beaten path, but that doesn't mean we won't still > furnish a very clear "approved path" and make it equally clear that > people walking elsewhere do so at their own risk. I suddenly have to think about the Garden of Eden, apples and snakes. I think that making it easy for people to choose "the path less travelled by" is not necessarily a bad thing. But I don't think we can get away with the idea that it's at their own risk if they do so. You can't expect people to not go through doors you hold open for them. You can't also expect that only the "right" people go through those doors. How do you see the demand for support in such a flexible environment? > > For example: The question "Did you test your changes with a make world?" > > would be completely meaningless. > > Not at all. It just becomes true that "make world" only has meaning > for those tracking one of the standard configuration sets, just as it > currently holds meaning only for those who don't manually hack their > /usr/src trees before making the world. I assume that tracking one of the configuration sets means that these sets will differ only to small extends that we avoid the problem that commits tested with one configuration can break another configuration? If so, how does that allow us to create a configuration in which we replace a core tool, such as a compiler so that we can benefit from it on certain platforms? If not, doesn't that only exaggerate the problem we already have between different platforms? > More flexible mechanisms don't automatically imply that policy is > sacrificed as a side-effect. Agreed. > Actually, if one looks to the real world > for examples, it would appear that policies actually become even more > strict and well-defined as the mechanisms become more flexible. They > have to. True. Do you see a benefit for FreeBSD when this happens? Don't you think that strictness and well-definedness and FreeBSD developers don't go together? Can you say style(9)? :-) > I therefore can't really see a > supporting argument for lumping policy and mechanism together from > *either* side of the coin. I have my doubts that policy without it being enforced by mechanism will survive. The discussions on the subject of style(9) can't be that easily forgotten. I do see the advantages of policy-free mechanisms; I just question our ability to enforce policies upon ourselves without the aid of policy enforcing mechanisms... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 0:26:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8497637B401; Mon, 19 Feb 2001 00:26:34 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1J8QYq03413; Mon, 19 Feb 2001 00:26:34 -0800 (PST) Date: Mon, 19 Feb 2001 00:26:34 -0800 From: Alfred Perlstein To: freebsd-arch@FreeBSD.ORG Cc: Jos Backus , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219002634.J6641@fw.wintelcom.net> References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010218235023.A95040@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Sun, Feb 18, 2001 at 11:50:24PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [010218 23:51] wrote: > On Sun, Feb 18, 2001 at 11:39:16PM -0800, Jos Backus wrote: > > > I can't help getting the impression that people don't care to give djbdns a > > proper look because of the way they perceive its author. Who cares what kind > > of personality the author has, as long as the code works and is > > well-supported? > > WE care if it has a license against the BSD philosophy. Period. There's that, but where's the years of auditing and real world use to back up the decision to include this code in our base system? Sure bind has had its problems, but all djbdns seems to have is obfucation and a small userbase as merits. -- -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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 0:26:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8497637B401; Mon, 19 Feb 2001 00:26:34 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1J8QYq03413; Mon, 19 Feb 2001 00:26:34 -0800 (PST) Date: Mon, 19 Feb 2001 00:26:34 -0800 From: Alfred Perlstein To: freebsd-arch@FreeBSD.ORG Cc: Jos Backus , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219002634.J6641@fw.wintelcom.net> References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010218235023.A95040@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Sun, Feb 18, 2001 at 11:50:24PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [010218 23:51] wrote: > On Sun, Feb 18, 2001 at 11:39:16PM -0800, Jos Backus wrote: > > > I can't help getting the impression that people don't care to give djbdns a > > proper look because of the way they perceive its author. Who cares what kind > > of personality the author has, as long as the code works and is > > well-supported? > > WE care if it has a license against the BSD philosophy. Period. There's that, but where's the years of auditing and real world use to back up the decision to include this code in our base system? Sure bind has had its problems, but all djbdns seems to have is obfucation and a small userbase as merits. -- -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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 0:28: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 6F3C337B4EC for ; Mon, 19 Feb 2001 00:28:04 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1J8MOH16344; Mon, 19 Feb 2001 00:22:24 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Marcel Moolenaar Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things In-Reply-To: Message from Marcel Moolenaar of "Sun, 18 Feb 2001 23:57:47 PST." <3A90D1FB.D02C2931@cup.hp.com> Date: Mon, 19 Feb 2001 00:22:24 -0800 Message-ID: <16340.982570944@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I suddenly have to think about the Garden of Eden, apples and snakes. If you want to benefit from the eating of the apple of knowledge, you have to be prepared to contend with the occasional snake too. :) > If so, how does that allow us to create a configuration in which we > replace a core tool, such as a compiler so that we can benefit from it > on certain platforms? Radical surgery like that is always risky, all we're suggesting is that the surgeons be given something a little better than a bottle of whiskey and a rusty razor blade to work with. > True. Do you see a benefit for FreeBSD when this happens? Don't you > think that strictness and well-definedness and FreeBSD developers don't > go together? Can you say style(9)? Absolutely. Just because some developers have a problem with style(9) doesn't mean it's a bad idea or that we should never ever write something like the style(9) man page again just because the last such document wasn't followed with 100% slavish compliance. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 0:48:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 0F9D137B401 for ; Mon, 19 Feb 2001 00:48:09 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1J8m8n96466 for arch@FreeBSD.ORG; Mon, 19 Feb 2001 00:48:08 -0800 (PST) (envelope-from obrien) Date: Mon, 19 Feb 2001 00:48:07 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: Moving Things Message-ID: <20010219004807.B95040@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3A908324.EF6F4385@cup.hp.com> <200102190501.WAA12085@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102190501.WAA12085@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 19, 2001 at 05:01:55AM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 05:01:55AM +0000, Terry Lambert wrote: > Windows practically lets you add or remove much of the OS, Much of the OS? Has win2k added that much granularity over NT4? In NT4 you can remove a few MB of very extraneous stuff. It certainly doesn't give you any real degree of granularity to remove things. Say their lame telnet/ftp/traceroute/etc.. utils. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 0:58:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id BC30E37B491 for ; Mon, 19 Feb 2001 00:58:46 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1J8wjQ96671 for arch@FreeBSD.ORG; Mon, 19 Feb 2001 00:58:45 -0800 (PST) (envelope-from obrien) Date: Mon, 19 Feb 2001 00:58:45 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219005845.C95040@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> <20010219002634.J6641@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: <20010219002634.J6641@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Feb 19, 2001 at 12:26:34AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 12:26:34AM -0800, Alfred Perlstein wrote: > There's that, but where's the years of auditing and real world use > to back up the decision to include this code in our base system? The next major version of BIND is a complete re-write. So all the auditors will have to start from scratch. So your argument doesn't hold so well. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 1: 6:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id A94AA37B401 for ; Mon, 19 Feb 2001 01:06:44 -0800 (PST) Received: (qmail 85994 invoked by uid 1000); 19 Feb 2001 09:07:04 -0000 Date: Mon, 19 Feb 2001 01:06:42 -0800 From: Jos Backus To: Alfred Perlstein Cc: freebsd-arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219010642.F56133@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: Alfred Perlstein , freebsd-arch@FreeBSD.ORG References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> <20010219002634.J6641@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: <20010219002634.J6641@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Feb 19, 2001 at 12:26:12AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 12:26:12AM -0800, Alfred Perlstein wrote: > There's that, but where's the years of auditing and real world use > to back up the decision to include this code in our base system? In a sense it's a chicken and egg problem. The software is fairly young, yes. I guess it partly depends on a human factor: whether you trust Dan to write secure and reliable code. However, experience has shown that FreeBSD includes software in its base system which has shown repeatedly to be insecure and unreliable. So this auditability argument doesn't really hold water in my view. Besides, Dan's code should be easier to audit because it is much smaller and much more modular. > Sure bind has had its problems, but all djbdns seems to have is > obfucation and a small userbase as merits. Its userbase is growing. Maybe Dan can back this up with real numbers (I suspect it's one of the reasons he runs these surveys he does). I'm not sure what you mean by the obfuscation argument. People on the djb-dns list have already come up with patches, which means that they at least have some understanding of the code or else they would not be able to do that. Surely the bright people of the FreeBSD project have no trouble reading Dan's code once they set their minds to it. It's nowhere nearly as complex as the TCP/IP stack, for example. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 1:15:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 3678237B503 for ; Mon, 19 Feb 2001 01:15:38 -0800 (PST) Received: (qmail 46960 invoked by uid 1000); 19 Feb 2001 09:15:59 -0000 Date: Mon, 19 Feb 2001 01:15:37 -0800 From: Jos Backus To: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219011537.G56133@lizzy.bugworks.com> Reply-To: Jos Backus References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> <20010219002634.J6641@fw.wintelcom.net> <20010219005845.C95040@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010219005845.C95040@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Mon, Feb 19, 2001 at 12:58:23AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 12:58:23AM -0800, David O'Brien wrote: > The next major version of BIND is a complete re-write. So all the > auditors will have to start from scratch. So your argument doesn't hold > so well. Thank you. But I agree that the license issue is problematic. Meanwhile I have sent Dan e-mail asking him to think about changing djbdns in such a away that the patches to the port can go. That's a start. In my view this particular discussion should not be about products (BIND versus djbdns), it should be about how to provide DNS services on FreeBSD in the most secure and reliable way. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 2:12:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 189D737B4EC for ; Mon, 19 Feb 2001 02:12:20 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id DAA19341; Mon, 19 Feb 2001 03:07:14 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAg8a4TL; Mon Feb 19 03:07:05 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA17412; Mon, 19 Feb 2001 03:12:05 -0700 (MST) From: Terry Lambert Message-Id: <200102191012.DAA17412@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: josb@cncdsl.com Date: Mon, 19 Feb 2001 10:12:05 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010218233916.J28286@lizzy.bugworks.com> from "Jos Backus" at Feb 18, 2001 11:39:16 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I can't help getting the impression that people don't care to give djbdns a > proper look because of the way they perceive its author. Who cares what kind > of personality the author has, as long as the code works and is > well-supported? I looked at DJBDNS in serious detail, for use on a datacenter project within IBM. I found it wanting. Before that, I looked at it on each of its major releases, at least those which Dan posted to the IETF DNSEXT working group, where I was a participant. I found it wanting on each of these occasions. Unfortunately, it requires static configuration; in other words, every DJBDNS server believes that it's the primary. This would have cause significant problems for dynamic updates, which were needed for email relay by dynamic IP customers wanting to send email. Patching the server to permit these updates to occur automatically would not work, due to the license. This could maybe be lived with. Because all servers are "primary", and they have the same weight, as far as being authoritative servers, this means that updates to one server's data must be made to both servers. Worse, both must then be restarted for the updates to take effect. Even if I could ignore the problem with not being able to update a single server and have the secondaries "just work" because of NOTIFY, the need to shoot all my name servers in the head when I do an update is simply unacceptable. I can't rely on one server being up while another is reloading. With BIND, I only have to worry about this on zone creation, and I can stagger the reload on zone creates, so it's not really a problem. With DJBDNS, my hands are tied, and the frequency of update events when you have 500 customers doing an update each time they dial in, and dialing in once an hour or even more frequently, with another update on teardown, means that my DNS servers would be largely unavailable. No thank you. Philosophically, DJBDNS is Dan's baby; Dan is opposed to protocol level modification of DNS server contents. Philosophically, I want all of the operations on the server to occur over the protocol link, including zone creation in secondaries (it's trivial to permit zone creation in the primary in BIND; there is an over-zealous conditional test that should only be enforced on secondaries, since on a primary, there is a sufficient security association). Dan is strongly opposed to offering alternate back ends. There are patches to BIND 4.x to make it serve data out of an SQL database; for a recent project of my own, I've made BIND 8.4p (I'm not using the areas with the recent security hole, but I supposed I should update the changes to make them run in BIND 8.5) serve its data out of an LDAP directory. Dan wouldn't let me do this with his code. If his stated philosophy is still the same, he would oppose it on the basis of his license, and he would not integrate patches I sent him on the basis of LDAP servers not being up to his security standards, and, since permitting non-static configuration, he would consider it a security hole that someone could modify the server contents over a protocol level link. I definitely buy into the basic idea that minimal servers with discrete roles can lend themselves to better security; I don't really buy the idea that having this architecture automatically results in better security, instead of just a false sense that there's better security. You have to wonder why DJBDNS isn't run from a program that opens the listen socket, relinquishes credentials, and then exec's the actual program, with close-on-exec unset only on the descriptors to the socket and data files (pened read-only before the exec, naturally). As to hackability: the other posters are right: why I want to hack it is up to me, and it doesn't matter why, only whether or not I can. As a service, I could probably hack the code (assuming I never wanted to license it out, and only ever sold service, which is the revenue model used by most of the failing ASP's and B2B's in the exchange business). I would be at risk, though: I wouldn't be able to go public, or be acquired, since that would constitute sale of the business, and therefore sale of the code. When I brought up the issue of the old Soft Updates license being a problem for Best Internet, I wasn't joking: technically, they were using Soft Updates legally, but sale of their business when they were acquired could have triggered the license clause which prohibited FreeBSD from being shipped with the code compiled into the kernel and enabled by default. Even ignoring my own hacking of the code, just like I can compile GPL code into the kernel, and use it myself, the patches on the DJBDNS port to make it work with FreeBSD have the same "binary nerve gas" effect, which would technically require that, before the sale of my business, the code be removed, and after the sale of the business, the code be recompiled and reinstalled by the new owners, since I can't distribute it that way, and still have a legal license to use the code. It's too much of a headache, and, from my personal point of view, and in accordance with the philosophy of an integrated, uncached control store (so that configuration changes take effect immediately), his code is seriously lacking. PS: on a similar note, I think there should be a 10 second or so timer in inetd, and it should stat the inetd.conf file for changes, so we no longer have to put up with cached state until we HUP the thing. I think "init" should have a similar thing for /etc/ttys; cached state data is inherently bad everywhere, not just in DNS servers. PPS: I think that reverse record updates should be permitted on the basis of having a forward record, and a request from the IP address of the machine the forward record points to, so I have some problems with BIND, as well, but at least they are limited to IPv6 stateless autoconfiguration and zone creation via DNSUPDAT in secondaries. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 2:18: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CAE5937B401 for ; Mon, 19 Feb 2001 02:17:59 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1JAHvJ06940; Mon, 19 Feb 2001 02:17:57 -0800 (PST) Date: Mon, 19 Feb 2001 02:17:57 -0800 From: Alfred Perlstein To: Terry Lambert Cc: josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219021757.L6641@fw.wintelcom.net> References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102191012.DAA17412@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 19, 2001 at 10:12:05AM +0000 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [010219 02:12] wrote: > > PS: on a similar note, I think there should be a 10 second or so > timer in inetd, and it should stat the inetd.conf file for changes, > so we no longer have to put up with cached state until we HUP the > thing. I think "init" should have a similar thing for /etc/ttys; > cached state data is inherently bad everywhere, not just in DNS > servers. > You scare me, I was thinking just the same thing about mountd earlier today. Only problem is that it violates POLA(* heh), one could offer an command line option to have it watch the file. (*) tmpwatch Another idea, instead of having to graft some interface and repeat it over and over with inetd/mountd/init, one could even write a program whos responsibility it was to sit in a poll()/kevent() look watching these conf files and sending the appropriate signals to them. Of course it would monitor its own config file for changes. :) -- -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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 2:32:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 8CAF337B401 for ; Mon, 19 Feb 2001 02:32:11 -0800 (PST) Received: (qmail 33690 invoked by uid 1000); 19 Feb 2001 10:30:16 -0000 Date: Mon, 19 Feb 2001 12:30:15 +0200 From: Peter Pentchev To: Terry Lambert Cc: josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219123015.D2946@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , josb@cncdsl.com, arch@FreeBSD.ORG References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102191012.DAA17412@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 19, 2001 at 10:12:05AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 19, 2001 at 10:12:05AM +0000, Terry Lambert wrote: > > I can't help getting the impression that people don't care to give djbdns a > > proper look because of the way they perceive its author. Who cares what kind > > of personality the author has, as long as the code works and is > > well-supported? > > I looked at DJBDNS in serious detail, for use on a datacenter > project within IBM. I found it wanting. > [snip] > Because all servers are "primary", and they have the same weight, > as far as being authoritative servers, this means that updates to > one server's data must be made to both servers. Worse, both must > then be restarted for the updates to take effect. Even if I could > ignore the problem with not being able to update a single server > and have the secondaries "just work" because of NOTIFY, the need > to shoot all my name servers in the head when I do an update is > simply unacceptable. I can't rely on one server being up while > another is reloading. With BIND, I only have to worry about this > on zone creation, and I can stagger the reload on zone creates, so > it's not really a problem. With DJBDNS, my hands are tied, and > the frequency of update events when you have 500 customers doing an > update each time they dial in, and dialing in once an hour or even > more frequently, with another update on teardown, means that my DNS > servers would be largely unavailable. No thank you. Now hold it, just a second! Restarting?! I'll not go into detail as to synchronizing djbdns data files via rsync (yet it *is* easily doable, esp. with ssh permitting passwordless authentication for executing a single command - in this case, sending over the new database and executing the rebuild command), but one of the djbdns features that I've found I like best over BIND is just that - tinydns does NOT need restarting when its data file changes! (if you meant you need to restart dnscache, see below.) (For those who haven't looked into djbdns, tinydns is the authoritative 'content' server, there's a separate program, 'dnscache', that does the recursive resolving thing.) tinydns never loads its datafile into memory, it mmap's it and does one-pass lookups on each and every query. The tinydns-data program, which is used to rebuild the database, works on a temporary file, and only atomically replaces the real database when finished. Thus, there's NO downtime updating the content server's DB. If your problem was with dnscache giving out stale information after a dynamic hostname has changed, may I ask why not use low TTL's, possibly of the order of half an hour or less? To reiterate, there is NO downtime associated with rebuilding a djbdns database, which is more than can be said for BIND. G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 4:16:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id 32F5737B401 for ; Mon, 19 Feb 2001 04:16:19 -0800 (PST) Received: from dungeon.home (ppp192.dyn248.pacific.net.au [203.143.248.192]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id XAA02373; Mon, 19 Feb 2001 23:16:13 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.11.1) with ESMTP id f1JCHno13825; Mon, 19 Feb 2001 22:17:49 +1000 (EST) (envelope-from mckay) Message-Id: <200102191217.f1JCHno13825@dungeon.home> To: Warner Losh Cc: arch@freebsd.org, mckay@thehub.com.au Subject: Re: The whole libc thing. References: <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> In-Reply-To: <200102170638.f1H6ckW84622@harmony.village.org> from Warner Losh at "Sat, 17 Feb 2001 06:38:46 +0000" Date: Mon, 19 Feb 2001 22:17:49 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 17th February 2001, Warner Losh wrote: >Case 3. I've installed a port that installs libfred.so.3 from 4.2 >release. It contains __sF references. I have a binary (say barney) >that links libfred.so.3 and libc.so.4. Things work now. I rebuild >the world. Things still work because neither of the above has >changed. Now let's say I want to build wilma that depends on libfred. >When wilma is built, it will fail to run because it links against >libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so >it will fail at link time or run time. This is easy to fix. Just >rebuild the port tht produced libfred.so.3. A new libfred.so.3 is >installed. wilma will now run (maybe after being rebuilt). barney >will also still run because it gets all the symbols it needs >(including the new libfred.so.3). Doesn't barney die due to unresolved references to __stdout (etc) from the recompiled libfred.so.3? It only has the old libc.so.4 to help it. Or are you proposing to regenerate all libc.so.* back to the ELF transition? I am still confused, and still concerned, and still think a global major version bump is unavoidable. Stephen. PS You might have to cc mckay@freebsd.org to be sure to reach me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 4:20:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8FC4137B401 for ; Mon, 19 Feb 2001 04:20:12 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA27740; Mon, 19 Feb 2001 13:20:08 +0100 (CET) (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: Jos Backus Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <20010218235023.A95040@dragon.nuxi.com> <20010219002634.J6641@fw.wintelcom.net> <20010219010642.F56133@lizzy.bugworks.com> From: Dag-Erling Smorgrav Date: 19 Feb 2001 13:20:07 +0100 In-Reply-To: Jos Backus's message of "Mon, 19 Feb 2001 01:06:42 -0800" Message-ID: Lines: 26 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jos Backus writes: > I'm not sure what you mean by the obfuscation argument. People on the djb-dns > list have already come up with patches, which means that they at least have > some understanding of the code or else they would not be able to do that. > Surely the bright people of the FreeBSD project have no trouble reading Dan's > code once they set their minds to it. The bright people of the FreeBSD project don't wanna. I strongly suggest that you refrain from discussing the quality of DJB's code and the feasability of auditing and integrating his code unless you are able, willing and prepared to do judge that quality first-hand and perform that audit and integration yourself. (I have first-hand experience with DJB's code, and would prefer to never have to look at it again, especially not in my free time.) > It's nowhere nearly as complex as the > TCP/IP stack, for example. Unlike DJB's code, the TCP/IP stack code is nicely formatted and well documented. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 5:59: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id D366937B503 for ; Mon, 19 Feb 2001 05:58:59 -0800 (PST) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.11.1/8.11.1) with ESMTP id f1JDxMa69874 for ; Mon, 19 Feb 2001 08:59:22 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 19 Feb 2001 08:59:22 -0500 (EST) From: Adam To: Subject: Re: Moving Things In-Reply-To: <20010219004807.B95040@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Feb 2001, David O'Brien wrote: >On Mon, Feb 19, 2001 at 05:01:55AM +0000, Terry Lambert wrote: >> Windows practically lets you add or remove much of the OS, > >Much of the OS? Has win2k added that much granularity over NT4? >In NT4 you can remove a few MB of very extraneous stuff. It certainly >doesn't give you any real degree of granularity to remove things. Say >their lame telnet/ftp/traceroute/etc.. utils. > >-- >-- David (obrien@FreeBSD.org) > GNU is Not Unix / Linux Is Not UniX Unfortunately the opposite. During the installation of win2k, it asks even less questions and installs way more than nt4 did in terms of megabytes. I haven't seen myself or heard of a way to uninstall components that used to be optional either, and win2k does a good job of making sure you cant delete them manually. Attempts to delete just about any file that win2k thinks is important will trigger Windows File Protection to put another copy in from its magical stash, or ask for the cd ;( Might be great for OS integrity but a big pain in the butt for the intermediate user who knows what they are doing but not how to hack the registry to disable WFP. Windows 2000 has an even bigger problem than FreeBSD in installation granularity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 6:18:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A5E437B503 for ; Mon, 19 Feb 2001 06:18:40 -0800 (PST) Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id PAA19123; Mon, 19 Feb 2001 15:16:07 +0100 Date: Mon, 19 Feb 2001 15:16:07 +0100 From: Christoph Hellwig To: Nate Williams Cc: Terry Lambert , "Matthew N. Dodd" , Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010219151607.A18841@caldera.de> References: <200102170951.CAA28641@usr05.primenet.com> <14990.45415.531767.116635@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14990.45415.531767.116635@nomad.yogotech.com>; from nate@yogotech.com on Sat, Feb 17, 2001 at 10:14:15AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 10:14:15AM -0700, Nate Williams wrote: > > > > I'd really like to see the wall between "base" and "ports" broken down. > > > > > > base system > > > layered software packages > > > 3rd party software packages > > > > > > Humm... I seem to recall another OS that did this sort of thing -20- years > > > ago. > > > > SCO did this. > > Sys III did this, ~20 years ago. At least the Sys III source tree I have does not have this feature... Christoph -- Of course it doesn't work. We've performed a software upgrade. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 8:28: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 010BF37B503 for ; Mon, 19 Feb 2001 08:27:31 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14UtBM-0000XB-00; Mon, 19 Feb 2001 09:29:01 -0700 Message-ID: <3A9149CC.7A1FADB8@softweyr.com> Date: Mon, 19 Feb 2001 09:29:00 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jos Backus Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jos Backus wrote: > > [This is rapidly turning into a bikeshed...] > > On Mon, Feb 19, 2001 at 12:25:50AM -0700, Wes Peters wrote: > > Some of the assumptions behind the operation of djbdns may not hold true > > for your installation. > > Some of those behind BIND's operation may not either. > > BIND's instability and problems are costing people and companies all over the > world real time and money. But with BIND, you the user can fix them. You can do that with DJBDNS, too, but you can't share your fixes with anyone else. > > That, along with the unmaintainability of the software fails to convince me > > it is a viable replacement for BIND. > > Again, what's there to maintain? Fix bugs/security problems? Dynamic DNS? DNSSEC? Cache control and forwarding? > I can't help getting the impression that people don't care to give djbdns a > proper look because of the way they perceive its author. Who cares what kind > of personality the author has, as long as the code works and is > well-supported? That's just the point, it ISN'T well-supported. DJB has his idea of how the world works, and if your idea doesn't match his, he doesn't integrate the code. I *have* worked with tinydns, modified it to perform some special tricks we needed for a partially connected server/gateway, and found that we could not distribute the modified versions, and DJB was not interested in our custom hacks. So we flushed tinydns and went with our own custom program AND bind. You seem to completely miss the fact that it's NOT DJB's code we really object to, but rather the license. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 9:26:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4D65C37B491 for ; Mon, 19 Feb 2001 09:26:29 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1JHPqW61137; Mon, 19 Feb 2001 10:25:57 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102191725.f1JHPqW61137@harmony.village.org> To: Jos Backus Subject: Re: DJBDNS vs. BIND Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Feb 2001 23:39:16 PST." <20010218233916.J28286@lizzy.bugworks.com> References: <20010218233916.J28286@lizzy.bugworks.com> <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> Date: Mon, 19 Feb 2001 10:25:52 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010218233916.J28286@lizzy.bugworks.com> Jos Backus writes: : [This is rapidly turning into a bikeshed...] It is perfect bikeshed material. : > That, along with the unmaintainability of the software fails to convince me : > it is a viable replacement for BIND. : : Again, what's there to maintain? Fix bugs/security problems? It is a showstopper to have readonly code in the tree. That has been FreeBSD's policy for a long time. If there's a security bug, we'd be prevented from fixing it until the author could be contacted and he produces a fix, that's unacceptible. We'd be prevented from even fixing a #include name that the author somehow got wrong. The author is also an jerk to deal with, that's strike two. He's at least two orders of magnituded harder to deal with than any other author of software we have in the tree. In short, I don't care if djbdns is better than bind, it won't go into the tree because of these problems. The license and author combined make it a showstopper. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 9:34:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 69D5C37B4EC; Mon, 19 Feb 2001 09:34:27 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1JHYQW61198; Mon, 19 Feb 2001 10:34:27 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102191734.f1JHYQW61198@harmony.village.org> To: Stephen McKay Subject: Re: The whole libc thing. Cc: arch@freebsd.org In-reply-to: Your message of "Mon, 19 Feb 2001 22:17:49 +1000." <200102191217.f1JCHno13825@dungeon.home> References: <200102191217.f1JCHno13825@dungeon.home> <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> Date: Mon, 19 Feb 2001 10:34:26 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102191217.f1JCHno13825@dungeon.home> Stephen McKay writes: : >Case 3. I've installed a port that installs libfred.so.3 from 4.2 : >release. It contains __sF references. I have a binary (say barney) : >that links libfred.so.3 and libc.so.4. Things work now. I rebuild : >the world. Things still work because neither of the above has : >changed. Now let's say I want to build wilma that depends on libfred. : >When wilma is built, it will fail to run because it links against : >libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so : >it will fail at link time or run time. This is easy to fix. Just : >rebuild the port tht produced libfred.so.3. A new libfred.so.3 is : >installed. wilma will now run (maybe after being rebuilt). barney : >will also still run because it gets all the symbols it needs : >(including the new libfred.so.3). : : Doesn't barney die due to unresolved references to __stdout (etc) from : the recompiled libfred.so.3? It only has the old libc.so.4 to help it. : Or are you proposing to regenerate all libc.so.* back to the ELF : transition? I am still confused, and still concerned, and still : think a global major version bump is unavoidable. I am saying that we regenerate libc.so.[34]. barney then wouldn't die from the missing symbol and life would be good, assuming that no macros used _up, which I'm nearly positive none do. We've added symbols like this in the past for various reasons, but maybe never so late in the 3.x branch. We also have the technology to regenerate the libc.so.[34] in place if we needed to w/o recompiling, but polishing it for the great masses will take some time. After talking with Peter on IRC extensively about this, I think that we need a bigger window where we generate __stdout before trying to take the plunge. There are still too many libraries that depend on __sF. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:13: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cosmo.jt.org (cosmo.jt.org [206.14.191.190]) by hub.freebsd.org (Postfix) with SMTP id 6EDC737B491 for ; Mon, 19 Feb 2001 10:13:05 -0800 (PST) Received: (qmail 98264 invoked by uid 1000); 19 Feb 2001 18:12:34 -0000 Date: Mon, 19 Feb 2001 10:12:34 -0800 From: Dan Peterson To: arch@freebsd.org Subject: Re: DJBDNS vs. BIND Message-ID: <20010219101234.A98114@danp.net> References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <3A9149CC.7A1FADB8@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9149CC.7A1FADB8@softweyr.com>; from wes@softweyr.com on Mon, Feb 19, 2001 at 09:29:00AM -0700 X-PGP-Key: http://danp.net/pubkey.asc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > but you can't share your fixes with anyone else. http://www.djbdns.org > Dynamic DNS? I can't say I've ever used this. Sounds like another BIND klugde, though. It would probably be easier to write a simple script to edit your data file and rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . > DNSSEC? http://cr.yp.to/djbdns/forgery.html > Cache control and forwarding? RTFM at http://cr.yp.to/djbdns/dnscache.html . > and found that we could not distribute the modified versions Again, http://www.djbdns.org . > You seem to completely miss the fact that it's NOT DJB's code we really > object to, but rather the license. I don't really care about djbdns being in the base system; I just want people to stop spreading misinformation. -- Dan Peterson http://danp.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:26: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4075E37B401 for ; Mon, 19 Feb 2001 10:25:56 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JIPde37350; Mon, 19 Feb 2001 10:25:39 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 10:25:39 -0800 (PST) From: Matt Dillon Message-Id: <200102191825.f1JIPde37350@earth.backplane.com> To: Terry Lambert Cc: josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102191012.DAA17412@usr05.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :When I brought up the issue of the old Soft Updates license being :a problem for Best Internet, I wasn't joking: technically, they :were using Soft Updates legally, but sale of their business when :they were acquired could have triggered the license clause which :prohibited FreeBSD from being shipped with the code compiled into :the kernel and enabled by default. Huh? It was a while ago but I am fairly certain I sent a Kirk a check for our use of softupdates at BEST. I understand your point, though, but it's a rather severe interpretation and I don't think it applies to either softupdates or DJBDNS. In anycase, the basic problem with DJBDNS is not that it couldn't be made into a port -- DJB's distribution license does not prevent us from creating a port with patches. The problem is that (A) The code is uncommented and so badly formatted as to be essentially unreadable, making it difficult to maintain by anyone outside of the author himself, and (B) no significant changes can be made with any hope of them being reincorporated into the base source due to DJB's rather severe ideas about what DJBDNS should be. This means that DJBDNS is essentially frozen, except for relatively minor bug fixes and features which DJB decides fit in his world view, which means that it is likely to wind up in the dustbin of history. In my view, it is not a good long term bet. All you have to do is read his documentation to see the deadend up ahead. Even DJB's refusal to simply clarify the licensing issues, and his attitude on his own mailing list points to this larger issue and we should simply avoid the whole mess and not try to support the software. Bind is a different story. Yes, Bind is definitely less secure. On the otherhand, Paul Vixie has accepted or implemented just about all the changes I've ever submitted to him. The only one he didn't accept was the parallel-restart change that I used at BEST to reduce downtime when restarting named. I eventually threw that one away myself. Bind may have too *many* features, but this doesn't mean it won't be cleaned up in the future (Bind9 is a good example of Paul realizing how much of a mess Bind8 became and acting on that information). And Bind isn't going to live or die with Paul. Bind is a good long term bet. -Matt :It's too much of a headache, and, from my personal point of view, :and in accordance with the philosophy of an integrated, uncached :control store (so that configuration changes take effect immediately), :his code is seriously lacking. :... : Terry Lambert : terry@lambert.org :--- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:29:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4732437B491 for ; Mon, 19 Feb 2001 10:29:12 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JIT6l37371; Mon, 19 Feb 2001 10:29:06 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 10:29:06 -0800 (PST) From: Matt Dillon Message-Id: <200102191829.f1JIT6l37371@earth.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com> <20010219021757.L6641@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> cached state data is inherently bad everywhere, not just in DNS :> servers. :> : :You scare me, I was thinking just the same thing about mountd :earlier today. Only problem is that it violates POLA(* heh), one :could offer an command line option to have it watch the file. I was thinking just having a 'mountd -reload'. I don't like the idea of programs polling configuration files. I actually used a similar mechanism in Diablo and wound up having to add hacks to, for example, try to avoid catching a configuration file in the middle of being written out by an editor. A better way would be to take the 'vipw' concept and write a general system utility to edit configuration files that does the right thing when you write the config file out (heh heh... based on.... another config file!). -Matt :(*) tmpwatch : :Another idea, instead of having to graft some interface and repeat :it over and over with inetd/mountd/init, one could even write a :program whos responsibility it was to sit in a poll()/kevent() look :watching these conf files and sending the appropriate signals to :them. Of course it would monitor its own config file for changes. ::) : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:32:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5999937B491 for ; Mon, 19 Feb 2001 10:32:11 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1JIW8h98294; Mon, 19 Feb 2001 13:32:08 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Feb 2001 13:32:08 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dan Peterson Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND In-Reply-To: <20010219101234.A98114@danp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Feb 2001, Dan Peterson wrote: > > Dynamic DNS? > > I can't say I've ever used this. Sounds like another BIND klugde, > though. It would probably be easier to write a simple script to edit > your data file and rebuild data.cdb. RTFM at > http://cr.yp.to/djbdns/tinydns-data.html . Hmm. Dynamic DNS sounds like it might be in the IETF standards track, actually. Please take a look at RFC 3007. > > DNSSEC? > > http://cr.yp.to/djbdns/forgery.html DNSsec specifies two things: syntax, and semantics. Name servers are welcome to implement whatever certification process they'd like: it doesn't have to include the DNS root, it's welcome to include peers, etc. Many people are critical of the DNSsec root model, but you're not forced to use that. You can implement any certification and trust policy you like. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:34:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1645B37B491 for ; Mon, 19 Feb 2001 10:34:29 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1JIXxh98301; Mon, 19 Feb 2001 13:33:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Feb 2001 13:33:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: Alfred Perlstein , Terry Lambert , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND In-Reply-To: <200102191829.f1JIT6l37371@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Feb 2001, Matt Dillon wrote: > :> cached state data is inherently bad everywhere, not just in DNS > :> servers. > :> > : > :You scare me, I was thinking just the same thing about mountd > :earlier today. Only problem is that it violates POLA(* heh), one > :could offer an command line option to have it watch the file. > > I was thinking just having a 'mountd -reload'. I don't like the > idea of programs polling configuration files. I actually used a > similar mechanism in Diablo and wound up having to add hacks to, > for example, try to avoid catching a configuration file in the middle > of being written out by an editor. Yeah -- automatic rereading of configuration files worries me also. You can end up with races during a file-rewrite. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:35:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E89F637B4EC for ; Mon, 19 Feb 2001 10:35:38 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1JIZVe18306; Mon, 19 Feb 2001 10:35:31 -0800 (PST) Date: Mon, 19 Feb 2001 10:35:31 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Terry Lambert , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219103531.N6641@fw.wintelcom.net> References: <200102191012.DAA17412@usr05.primenet.com> <200102191825.f1JIPde37350@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102191825.f1JIPde37350@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Feb 19, 2001 at 10:25:39AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010219 10:26] wrote: > :When I brought up the issue of the old Soft Updates license being > :a problem for Best Internet, I wasn't joking: technically, they > :were using Soft Updates legally, but sale of their business when > :they were acquired could have triggered the license clause which > :prohibited FreeBSD from being shipped with the code compiled into > :the kernel and enabled by default. > > Huh? It was a while ago but I am fairly certain I sent a Kirk a > check for our use of softupdates at BEST. I understand your point, > though, but it's a rather severe interpretation and I don't think > it applies to either softupdates or DJBDNS. I think Terry is tossing the idea around that it would or couldn't be possible for a company aquisition to transfer all software licenses. If this is how it works, suddenly whomever bought Best got to use softupdates in a much larger setup than Kirk probably initially thought. Sort of like Foocom Inc buying a license to ship several hundred units a year at a bargain price then having Sun swallow them and take advantage of the license. If this isn't how it works, then whomever bought Best might have been in for a lot of trouble depending on how much Best itself relied on softupdates to function. If the license was non-transferable even through aquisition then it might render a lot of Best's technology useless. All this is speculation, I'm sure Best liked softupdates, but could have managed without them. :) -- -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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:44:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cosmo.jt.org (cosmo.jt.org [206.14.191.190]) by hub.freebsd.org (Postfix) with SMTP id 75CD437B401 for ; Mon, 19 Feb 2001 10:44:09 -0800 (PST) Received: (qmail 98736 invoked by uid 1000); 19 Feb 2001 18:43:38 -0000 Date: Mon, 19 Feb 2001 10:43:38 -0800 From: Dan Peterson To: arch@freebsd.org Subject: Re: DJBDNS vs. BIND Message-ID: <20010219104338.B98114@danp.net> References: <20010219101234.A98114@danp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@freebsd.org on Mon, Feb 19, 2001 at 01:32:08PM -0500 X-PGP-Key: http://danp.net/pubkey.asc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm on the list. Please direct replies accordingly. Robert Watson wrote: > Hmm. Dynamic DNS sounds like it might be in the IETF standards track, > actually. Please take a look at RFC 3007. That doesn't mean it's not a hack. Would RFC 2317 be around if BIND wasn't? I don't see any RFC's specific to Sendmail's sendmail.cf format (and subsequent "standards track" documents to get around its deficiencies). > Name servers are welcome to implement whatever certification process > they'd like: it doesn't have to include the DNS root, it's welcome to > include peers, etc. Many people are critical of the DNSsec root model, but > you're not forced to use that. If it doesn't start at the roots, what good is it? Sure, you can make sure records within your own zones are "secure," but that's pretty much a given anyway. What about results from recursive queries to the Internet? DNSSEC is meaningless unless it goes from the roots up. -- Dan Peterson http://danp.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 10:54:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id EBC9337B503 for ; Mon, 19 Feb 2001 10:54:18 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1JIsBQ37549; Mon, 19 Feb 2001 10:54:11 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 10:54:11 -0800 (PST) From: Matt Dillon Message-Id: <200102191854.f1JIsBQ37549@earth.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102191012.DAA17412@usr05.primenet.com> <200102191825.f1JIPde37350@earth.backplane.com> <20010219103531.N6641@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I think Terry is tossing the idea around that it would or couldn't be :possible for a company aquisition to transfer all software licenses. :... : :If this isn't how it works, then whomever bought Best might have :been in for a lot of trouble depending on how much Best itself :relied on softupdates to function. If the license was non-transferable :even through aquisition then it might render a lot of Best's :technology useless. : :All this is speculation, I'm sure Best liked softupdates, but could :have managed without them. :) : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Unless the license explicitly indicates that it is not transferable, then a merger or buyout will have no effect on it. Patent-related licenses often have such a clause in them in order to allow the patent holder to renegotiate the terms (e.g. if a tiny company is aquired by a larger one). A site-license, on the otherhand, does not usually have such a clause because it is already inherently limiting the number of seats the software can be used with. Many open source licenses distinguish between commercial and non-commercial use, and a change of status would certainly apply there (e.g. a non-profit company merges with a for-profit company), but I don't know a single open source / freeware license that gives a damn whether a commercial company is being aquired by another commercial company. Most commercial-use licenses are site licenses. Custom license deals made by very large companies, e.g. a contract for MS to supply desktop software for example, are more likely to have change of control clauses in them for the purposes of renegotiation. But for smaller companies you rarely see this sort of thing because it's a waste of time and money. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 11:36:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 42E8A37B4EC for ; Mon, 19 Feb 2001 11:36:43 -0800 (PST) Received: from nomad.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA25342; Mon, 19 Feb 2001 12:35:35 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA01064; Mon, 19 Feb 2001 12:35:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14993.30081.750406.894363@nomad.yogotech.com> Date: Mon, 19 Feb 2001 12:35:29 -0700 (MST) To: Christoph Hellwig Cc: Nate Williams , Terry Lambert , "Matthew N. Dodd" , Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: <20010219151607.A18841@caldera.de> References: <200102170951.CAA28641@usr05.primenet.com> <14990.45415.531767.116635@nomad.yogotech.com> <20010219151607.A18841@caldera.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > I'd really like to see the wall between "base" and "ports" broken down. > > > > > > > > base system > > > > layered software packages > > > > 3rd party software packages > > > > > > > > Humm... I seem to recall another OS that did this sort of thing -20- years > > > > ago. > > > > > > SCO did this. > > > > Sys III did this, ~20 years ago. > > At least the Sys III source tree I have does not have this feature... The distribution for the IBM XT that I have has everything broken up into base system, layered software packages, and the manuals talk about 3rd party packages. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 12: 9:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 3888B37B491 for ; Mon, 19 Feb 2001 12:09:25 -0800 (PST) Received: (qmail 40267 invoked by uid 1001); 19 Feb 2001 20:09:22 +0000 (GMT) To: danp@danp.net Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 19 Feb 2001 10:43:38 -0800" References: <20010219104338.B98114@danp.net> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 19 Feb 2001 21:09:22 +0100 Message-ID: <40265.982613362@verdi.nethelp.no> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hmm. Dynamic DNS sounds like it might be in the IETF standards track, > > actually. Please take a look at RFC 3007. > > That doesn't mean it's not a hack. If it is on the IETF standards track, *and* it is used, and Dan Bernstein refuses to implement it, djbdns has a significant disadvantage. > Would RFC 2317 > be around if BIND wasn't? Yes. RFC 2317 describes a way to perform classless in-addr.arpa delegation. This is important due to CIDR. The fact that BIND zone file syntax is used in the examples does *not* mean that this is in any way tied to BIND. > I don't > see any RFC's specific to Sendmail's sendmail.cf format (and subsequent > "standards track" documents to get around its deficiencies). If you think that's the point of RFC 2317, I'd say you have misunderstood it rather badly. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 16: 8:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id CB9D737B503 for ; Mon, 19 Feb 2001 16:08:42 -0800 (PST) Received: (qmail 6473346 invoked from network); 20 Feb 2001 00:08:41 -0000 Received: from d165.dhcp212-231.cybercable.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 20 Feb 2001 00:08:41 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f1K08Xp71887; Tue, 20 Feb 2001 01:08:34 +0100 (CET) (envelope-from clefevre@poboxes.com) To: Terry Lambert Cc: marcel@cup.hp.com (Marcel Moolenaar), mark@grondar.za (Mark Murray), jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG Subject: Re: Moving Things References: <200102190501.WAA12085@usr05.primenet.com> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: Terry Lambert's message of "Mon, 19 Feb 2001 05:01:55 +0000 (GMT)" From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 20 Feb 2001 01:08:31 +0100 Message-ID: Lines: 14 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > I'm finding much sympathy with the Linux camp's assertion that > Linux is the kernel, and everything else is just a distribution... funny, that's exactly I don't like w/ GNU/Linux, the fact that the userland is not maintain the same way the kernel is, which make every GNU/Linux distributions so differents (read incompatible between them, a pain). Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17: 3:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C0B1F37B503 for ; Mon, 19 Feb 2001 17:03:41 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id RAA21458; Mon, 19 Feb 2001 17:57:30 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAA.ZaaXP; Mon Feb 19 17:57:21 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA04042; Mon, 19 Feb 2001 18:03:29 -0700 (MST) From: Terry Lambert Message-Id: <200102200103.SAA04042@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: danp@danp.net (Dan Peterson) Date: Tue, 20 Feb 2001 01:03:29 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010219101234.A98114@danp.net> from "Dan Peterson" at Feb 19, 2001 10:12:34 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > > but you can't share your fixes with anyone else. > > http://www.djbdns.org Unfortunately, I still can't sell my company, if I patch DJBDNS, and my company relies upon it, since I will be in violation of the license. > > Dynamic DNS? > > I can't say I've ever used this. Sounds like another BIND klugde, though. It > would probably be easier to write a simple script to edit your data file and > rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . DNSUPDAT, which is the proper name of the facility, allows you to make updates to zone data in the primary, without taking the server down, and without an outage while the server reloads its file. This can be used to make long TTL modifications to zone files, permanent changes to machine configurations within the zone. It is, however, most useful for dialup devices which need short TTL entries during the period of time which they are transiently connected. This is particularly useful for permitting a single relay policy for email (most dialup machines are blocked from direct mail into hosts controlled by sane administrators), and is also useful for "tickled" devices. A "tickled" device is one you call, it sees the ringing, and it calls in to establish a connection. It then makes a DNS entry with its dynamically assigned IP address, which permits you to dial in to get IP connectivity on a local number, and remotely access the dialup machine by name; without this, there's no way to know the IP address of the dynamic assignment. This facility is also useful for assigning DHCP lease names, and names based on RADIUS accounting records. I personally don't use this, since I think that machines should do their own stateless autoconfiguration, and DCHP should die. I don't use the RADIUS accounting records because I don't control a RADIUS server these days. > > DNSSEC? > > http://cr.yp.to/djbdns/forgery.html This is substantially incorrect. His reading is based on trusting an exterior zone on the basis of trusting a signature authority; if, on thge other hand, you want to establish your own security associations internally, perhaps going so far as to establish exterior associations with other companies for whom you have a record of their public keys, you can do so. Also, it is out of date: NSI has stated an intent to start signing, as soon as the RFC goes standard. Meanwhile, there's still the license. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:23:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 7754337B4EC for ; Mon, 19 Feb 2001 17:23:06 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id SAA29852; Mon, 19 Feb 2001 18:18:01 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA85a4q6; Mon Feb 19 18:17:54 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA04466; Mon, 19 Feb 2001 18:22:54 -0700 (MST) From: Terry Lambert Message-Id: <200102200122.SAA04466@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 20 Feb 2001 01:22:53 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <200102191829.f1JIT6l37371@earth.backplane.com> from "Matt Dillon" at Feb 19, 2001 10:29:06 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> cached state data is inherently bad everywhere, not just in DNS > :> servers. > : > :You scare me, I was thinking just the same thing about mountd > :earlier today. Only problem is that it violates POLA(* heh), one > :could offer an command line option to have it watch the file. > > I was thinking just having a 'mountd -reload'. I don't like the > idea of programs polling configuration files. I actually used a > similar mechanism in Diablo and wound up having to add hacks to, > for example, try to avoid catching a configuration file in the middle > of being written out by an editor. > > A better way would be to take the 'vipw' concept and write a general > system utility to edit configuration files that does the right thing > when you write the config file out (heh heh... based on.... another > config file!). You could close the file in between polls, and reopen it O_EXCL; or your vipw suggestion would also work, using a two stage commit to ensure that it was all or nothing for changes. Really, the program wants to sit on the file as part of its select loop, and when the file is closed so that it's the sole opener again, get an "exceptional condition" flagged in the select. Barring that, the next best thing is a signal, and the next best after that is a poll. The problem that needs to be addressed is the cached state which is no longer valid, but which has been cached on the basis of having read the configuration file. Sendmail has areas where there are similar problems on configuration changes (for example, it caches the name that it believes it is on startup, so if you change the host name in the DNS, it claims to be the old name, until it is restarted; similarly, it must be HUP'ed for a number of configuration file changes. Some of these can be worked around by using text files instead of databases, some can't). The inetd problem isn't isolated, it's just pretty glaring; the mountd one is too, but it's really hard to deal with, since there are ugly hooks for the FS exporting down in the VFS code, and managed per FS in the per FS mount code. This is really broken in BSD; SunOS, a long time ago, fixed this with the "exportfs" utility, and communicated the data to the kernel NFS server directly. In an ideal system, you would change the host name one place (for an example of commonly cached information), and everything would "just know" and "just do the right thing". Having an external program watching the configuration file changes is really a very poor approach, since it doesn't address the underlying problem very well. Windows tried to handle this for the most part by putting their registry interface into their kernel (the registry, the cache, and the dynamic portion of the registry tree are all wrapped up in a VXD). Unfortunately, they ended up doing a vast thing in a half-vast way (8-)), and still kept config.sys, autoexec.bat, and a bunch of .INI files, at the same time. A registry-like configuration store, which was cached by the OS, and was referenced directly each time the data was needed, instead of allowing the programs to cache data which might change would really be the best approach, but I rather think that it would be rejected because Microsoft had the idea. Heh. A new way to screw over your competitors: make them so hateful that they refuse to learn from your good ideas, and have to come up with something gratuitously different (and probably more complicated) just to be able to say that they aren't like you... 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 8AB4437B503 for ; Mon, 19 Feb 2001 17:23:44 -0800 (PST) Received: from gorean.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id RAA72463; Mon, 19 Feb 2001 17:23:42 -0800 (PST) (envelope-from DougB@gorean.org) Message-ID: <3A91C71D.D8ED44B3@gorean.org> Date: Mon, 19 Feb 2001 17:23:41 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dan Peterson Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <3A9149CC.7A1FADB8@softweyr.com> <20010219101234.A98114@danp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Peterson wrote: > > Wes Peters wrote: > > > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > > but you can't share your fixes with anyone else. > > http://www.djbdns.org > > > Dynamic DNS? > > I can't say I've ever used this. Sounds like another BIND klugde, though. It > would probably be easier to write a simple script to edit your data file and > rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . > > > DNSSEC? > > http://cr.yp.to/djbdns/forgery.html > > > Cache control and forwarding? > > RTFM at http://cr.yp.to/djbdns/dnscache.html . > > > and found that we could not distribute the modified versions > > Again, http://www.djbdns.org . > > > You seem to completely miss the fact that it's NOT DJB's code we really > > object to, but rather the license. > > I don't really care about djbdns being in the base system; I just want > people to stop spreading misinformation. It's not misinformation to say that djbdns doesn't implement dnssec. This is a typical (and unfortunate) response from someone who advocates djb's world view. Explaining why he thinks something isn't a good idea is not the same as implementing it. Similar points could be made for the other topics in this e-mail. The reasons for not putting djbdns in the base have been adequately made, I won't belabor them. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:38:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 445EB37B401 for ; Mon, 19 Feb 2001 17:38:52 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id SAA05583 for ; Mon, 19 Feb 2001 18:32:39 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAM1aO0k; Mon Feb 19 18:32:34 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA04793 for arch@freebsd.org; Mon, 19 Feb 2001 18:38:44 -0700 (MST) From: Terry Lambert Message-Id: <200102200138.SAA04793@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: arch@freebsd.org Date: Tue, 20 Feb 2001 01:38:44 +0000 (GMT) In-Reply-To: <20010219104338.B98114@danp.net> from "Dan Peterson" at Feb 19, 2001 10:43:38 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm on the list. Please direct replies accordingly. Please set the Reply-To:; it's a lot of work to send only to the list. 8-). > > Hmm. Dynamic DNS sounds like it might be in the IETF standards track, > > actually. Please take a look at RFC 3007. > > That doesn't mean it's not a hack. Would RFC 2317 > be around if BIND wasn't? I don't > see any RFC's specific to Sendmail's sendmail.cf format (and subsequent > "standards track" documents to get around its deficiencies). It doesn't matter if it's a hack or not (I happen to think it isn't, and supported it in the DNSEXT working group, along with Paul Vixie and others who I would not casually dismiss). If it is a standard, it is a standard, and it should be implemented, or your software is non-compliant. The reason for standards is so that we can assume a minimum level of functionality between peer implementations. It's an issue of interoperability, and playing nice with others. The IETF is, and has always been, about "rough consensus and working code". Subjective value judgements like "pretty" or "ugly" really don't enter into it. One of my favorite ways of restating Occam's Razor is "anything that works is better than anything that doesn't". > > Name servers are welcome to implement whatever certification process > > they'd like: it doesn't have to include the DNS root, it's welcome to > > include peers, etc. Many people are critical of the DNSsec root model, but > > you're not forced to use that. > > If it doesn't start at the roots, what good is it? Sure, you can make sure > records within your own zones are "secure," but that's pretty much a given > anyway. What about results from recursive queries to the Internet? DNSSEC is > meaningless unless it goes from the roots up. Aren't you one of those PGP signature users? 8-). Seriously, if it's not possible to route around NSI's damage, then the system needs a redesign. DJB's design is subject to the same damage (ignore the license issue, and assume free implementations of his design were available). The idea of a hierarchy with one true root implies that the holder of that root (if there is a holder) wields power over the rest of the hierarchy, deserved or not. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:47:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 0283437B4EC for ; Mon, 19 Feb 2001 17:47:57 -0800 (PST) Received: (qmail 1529 invoked from network); 19 Feb 2001 18:41:15 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 19 Feb 2001 18:41:15 -0000 Message-ID: <3A9168CB.7CF4D773@integratus.com> Date: Mon, 19 Feb 2001 10:41:15 -0800 From: Jack Rusher Organization: http://www.integratus.com/ X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dan Peterson Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <3A9149CC.7A1FADB8@softweyr.com> <20010219101234.A98114@danp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Peterson wrote: > > > Dynamic DNS? > > I can't say I've ever used this. Sounds like another BIND klugde, though. It > would probably be easier to write a simple script to edit your data file and > rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . We use this extensively as part of our wide area application level failover product. If you can't tell the DNS server the new service location, it's pretty hard to get requesters to redirects their requests to the healthy server. We could do this with a scripted hack involving ssh, but I prefer to do this through the documented (and IETF standardized) protocol that BIND supports. In short, this is important to us, not important to DJB, and he isn't interested in contributions, so we use BIND. I'm sure you will find a lot of people who can quote you variations on this theme. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:53:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from crewsoft.com (ns.aenet.net [157.22.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B20B37B491 for ; Mon, 19 Feb 2001 17:53:56 -0800 (PST) Received: from [172.17.1.25] (account cberger@wireless-networks.com HELO wireless-networks.com) by crewsoft.com (CommuniGate Pro SMTP 3.4b8) with ESMTP id 491565; Mon, 19 Feb 2001 17:56:40 -0800 Message-ID: <3A91CE37.F8C3FE80@wireless-networks.com> Date: Mon, 19 Feb 2001 17:53:59 -0800 From: Cedric Berger X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > A registry-like configuration store, which was cached by the OS, > and was referenced directly each time the data was needed, instead > of allowing the programs to cache data which might change would > really be the best approach, but I rather think that it would be > rejected because Microsoft had the idea. Microsoft??? the idea of registry??? If I remember my old university days, our VAX 11/780 had something very simmilar... Cedric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 17:57:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 089DA37B503 for ; Mon, 19 Feb 2001 17:57:48 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id SAB12765; Mon, 19 Feb 2001 18:51:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAApCai2y; Mon Feb 19 18:51:31 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA05156; Mon, 19 Feb 2001 18:57:40 -0700 (MST) From: Terry Lambert Message-Id: <200102200157.SAA05156@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 20 Feb 2001 01:57:40 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <200102191854.f1JIsBQ37549@earth.backplane.com> from "Matt Dillon" at Feb 19, 2001 10:54:11 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Many open source licenses distinguish between commercial and > non-commercial > use, and a change of status would certainly apply there (e.g. a > non-profit company merges with a for-profit company), but I don't know > a single open source / freeware license that gives a damn whether > a commercial company is being aquired by another commercial company. My point was that many of the licenses permit local modification, or local combination with software under other licenses, but prohibit distribution of the modified code (like Dan's license) or are inherently impossible to distribute and retain the legal license (like the commercial binaries we can't put on the FreeBSD CDROMs, or a FreeBSD kernel with a GPL'ed driver compiled into it). The Soft Updates license has changed. Before the change, there was a legal risk, which I don't believe Kirk would have pressed, unless there was an aggregious offense, that FreeBSD kernels with Soft Updates compiled into them could not have their ownership transferred, and retain license to use the code. This would have been real easy to work around, by having the new owners recompile the kernels with the Soft Updates, and thus make new, non-transferred combinations equivalent to the old ones. For DJBDNS, this would mean extracting the changes to the code as a set of patches, and then having the new owners apply the patches to the unaltered DJBDNS code, since the binaries of the modified code themselves are not permitted to be redistributed. There's a lot of skirting of the GPL that goes on out there, using the technique of requiring the end user to perform the link operation themselves, so that the proprietary code can continue to be proprietary, even when it's linked against, for example, GDBM (this gets around the "built to be linked only with the GPL'ed code equals a derivative work, since there are other DBM codes that can be used instead, so long as no GDBM specific interfaces were used). The Sleepycat licenses are similarly not redistributable, but you can build something that needs the libraries, and let the end user seperately obtain the code. The main point is that there is a lot of toxic licensing out there, and DJBDNS falls into that category. We couldn't make DJBDNS into a package instead of a port because the patches are not OK for a binary distribution. This basically means that it couldn't be an install option on whether you got DJBDNS or BIND, since installation really requires binaries in hand, or things end up getting too complex, taking a long time, and FreeBSD ends up looking bad at the worst possible time: the user's first exposure to the system, the install. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 18:27:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id E3B8F37B401 for ; Mon, 19 Feb 2001 18:27:35 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1K2RIA39581; Mon, 19 Feb 2001 18:27:18 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 18:27:18 -0800 (PST) From: Matt Dillon Message-Id: <200102200227.f1K2RIA39581@earth.backplane.com> To: Terry Lambert Cc: bright@wintelcom.net (Alfred Perlstein), tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200157.SAA05156@usr05.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :For DJBDNS, this would mean extracting the changes to the code as :a set of patches, and then having the new owners apply the patches :to the unaltered DJBDNS code, since the binaries of the modified :code themselves are not permitted to be redistributed. It means nothing of the sort. Unless DJBDNS explicitly says that a change of ownership (company bought, merger,... ) requires doing the above very silly thing, there is no legal risk whatsoever. A company being sold to another company is a very, very, very different beast then a company selling software commercially. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 18:28:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E60B337B401 for ; Mon, 19 Feb 2001 18:28:31 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id SAA17141; Mon, 19 Feb 2001 18:28:23 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda17138; Mon Feb 19 18:28:15 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1K2S5J04986; Mon, 19 Feb 2001 18:28:05 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdal4984; Mon Feb 19 18:27:17 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1K2RHv02933; Mon, 19 Feb 2001 18:27:17 -0800 (PST) Message-Id: <200102200227.f1K2RHv02933@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdzh2929; Mon Feb 19 18:27:15 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Cedric Berger Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND In-reply-to: Your message of "Mon, 19 Feb 2001 17:53:59 PST." <3A91CE37.F8C3FE80@wireless-networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 2001 18:27:15 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A91CE37.F8C3FE80@wireless-networks.com>, Cedric Berger writes: > Terry Lambert wrote: > > > A registry-like configuration store, which was cached by the OS, > > and was referenced directly each time the data was needed, instead > > of allowing the programs to cache data which might change would > > really be the best approach, but I rather think that it would be > > rejected because Microsoft had the idea. > > Microsoft??? the idea of registry??? > If I remember my old university days, our VAX 11/780 had something > very simmilar... That makes sense. Dave Cutler, chief NT architect, worked on VMS for DEC. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 18:37:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 91CB437B65D for ; Mon, 19 Feb 2001 18:37:18 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA16335; Mon, 19 Feb 2001 19:34:11 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAjaaG0F; Mon Feb 19 19:34:05 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA05931; Mon, 19 Feb 2001 19:37:08 -0700 (MST) From: Terry Lambert Message-Id: <200102200237.TAA05931@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: roam@orbitel.bg (Peter Pentchev) Date: Tue, 20 Feb 2001 02:37:03 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <20010219123015.D2946@ringworld.oblivion.bg> from "Peter Pentchev" at Feb 19, 2001 12:30:15 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Now hold it, just a second! Restarting?! > > I'll not go into detail as to synchronizing djbdns data files via > rsync (yet it *is* easily doable, esp. with ssh permitting passwordless > authentication for executing a single command - in this case, sending over > the new database and executing the rebuild command), but one of the djbdns > features that I've found I like best over BIND is just that - > > tinydns does NOT need restarting when its data file changes! > (if you meant you need to restart dnscache, see below.) > > (For those who haven't looked into djbdns, tinydns is the authoritative > 'content' server, there's a separate program, 'dnscache', that does > the recursive resolving thing.) > > tinydns never loads its datafile into memory, it mmap's it and does > one-pass lookups on each and every query. The tinydns-data program, > which is used to rebuild the database, works on a temporary file, > and only atomically replaces the real database when finished. > Thus, there's NO downtime updating the content server's DB. You still need to unmap the old file and remap the new file. It is my experience that the amount of time to turn around a change in data introduces an unacceptable propagation delay. This is compounded by having to do the changes to multiple DNS servers. With in excess of 50,000 lines of configuration data for 10,000 domains, the delay was very noticible. Further, the "synchronization is left as an exercise for the student" approach of having every server be primary, is incompatible with current network technology. In particular, a good DNS service provider will put DNS servers, minimally, at two colocation facilities, generally within spitting distance of MAE West and East, and better, five (add Chicago, France, and somewhere along the Pacific Rim). You are aware that with a West coast facility only, adding another DNS server on the East coast will increase your web site traffic by 30%, right? That's all accounted for by failures to reach your DNS server on the West coast; these are hit you are missing due to the users on the other end getting a lookup failure. I really did not want to deal with synchronization between S.F., Rochester NY, and Chicago, given the DJBDNS philosophy. Among other things, IBM will not open up SSH holes in its firewalls. With BIND and standard zone transfers, if I have a link lost between two DNS servers, then at least I am assured of NOTIFY synchronizing them at the first possible opportunity; if I had to roll my own, then I have to build all the retry logic into my code. Worse, it's probably written in a write-once language like Perl, since I'd give the job to someone else while I was tackling the things I really needed to worry about. It's just not worth it. > If your problem was with dnscache giving out stale information after > a dynamic hostname has changed, may I ask why not use low TTL's, > possibly of the order of half an hour or less? I generally use a TTL of 1 for transient records; this doesn't stop stupid programs from caching them (many people run caches which refuse to cache for anything less than 5 minutes to cut their DNS traffic). I'm safe on a redial, since the new record will replace the old record after authentication. Internally, I don't use cached data, since I have 100Mbit link between the mail and DNS servers. This means that as long as I get my updates to all my DNS servers _in a timely fashion_, I don't have the risk of using a stale DNS record, and shoving all my customer's mail down to some idiot's Linux box or Microsoft Exchange server, just because they have an open relay, and get the IP address that my customer used to have. > To reiterate, there is NO downtime associated with rebuilding > a djbdns database, which is more than can be said for BIND. There is propagation delay, which is effectively downtime, since I end up with the same latency, either way. Since BIND implements DNSUPDAT and DNSNOT, I have _no_ downtime (or latency, if you want to word-weasel) with BIND, because I don't have to rebuild the database at all to make the changes I need to make. The changes can be made without needing to do a rebuild at all. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 18:52:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 21D8937B491 for ; Mon, 19 Feb 2001 18:52:07 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA23678; Mon, 19 Feb 2001 19:47:02 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA.SaGmU; Mon Feb 19 19:46:58 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA06099; Mon, 19 Feb 2001 19:51:59 -0700 (MST) From: Terry Lambert Message-Id: <200102200251.TAA06099@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 20 Feb 2001 02:51:53 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <200102200227.f1K2RIA39581@earth.backplane.com> from "Matt Dillon" at Feb 19, 2001 06:27:18 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :For DJBDNS, this would mean extracting the changes to the code as > :a set of patches, and then having the new owners apply the patches > :to the unaltered DJBDNS code, since the binaries of the modified > :code themselves are not permitted to be redistributed. > > It means nothing of the sort. Unless DJBDNS explicitly says that > a change of ownership (company bought, merger,... ) requires doing > the above very silly thing, there is no legal risk whatsoever. > A company being sold to another company is a very, very, very > different beast then a company selling software commercially. Selling the company transfers ownership of the binaries. 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-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 21:23:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 0EB1337B401 for ; Mon, 19 Feb 2001 21:20:33 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14V5Ms-0000oV-00; Mon, 19 Feb 2001 22:29:43 -0700 Message-ID: <3A9200C6.AA3C8433@softweyr.com> Date: Mon, 19 Feb 2001 22:29:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Cy Schubert - ITSD Open Systems Group Cc: Cedric Berger , Terry Lambert , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200227.f1K2RHv02933@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > In message <3A91CE37.F8C3FE80@wireless-networks.com>, Cedric Berger > writes: > > Terry Lambert wrote: > > > > > A registry-like configuration store, which was cached by the OS, > > > and was referenced directly each time the data was needed, instead > > > of allowing the programs to cache data which might change would > > > really be the best approach, but I rather think that it would be > > > rejected because Microsoft had the idea. > > > > Microsoft??? the idea of registry??? > > If I remember my old university days, our VAX 11/780 had something > > very simmilar... > > That makes sense. Dave Cutler, chief NT architect, worked on VMS for > DEC. VMS had nothing remotely like the Windows Registry. Configuration data on VMS was mostly stored in the form of "logical names", which are sort of like persistent environment variables with different namespaces (per system, per group, and per user). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 21:27: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7C32D37B401 for ; Mon, 19 Feb 2001 21:27:03 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1K5R1h05838; Tue, 20 Feb 2001 00:27:01 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 20 Feb 2001 00:27:01 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dan Peterson Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND In-Reply-To: <20010219104338.B98114@danp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Feb 2001, Dan Peterson wrote: > > Name servers are welcome to implement whatever certification process > > they'd like: it doesn't have to include the DNS root, it's welcome to > > include peers, etc. Many people are critical of the DNSsec root model, but > > you're not forced to use that. > > If it doesn't start at the roots, what good is it? Sure, you can make > sure records within your own zones are "secure," but that's pretty much > a given anyway. What about results from recursive queries to the > Internet? DNSSEC is meaningless unless it goes from the roots up. A number of potential consumers of DNSsec are far more interested in non-root use that root-use. For example, in .mil and other large domains, the ability to secure between components of the organization is very useful. A number of companies and organizations are also interested in peer-based key sharing, where they introduce bounded trust for the peer's key to sign the peer's zone, which can then be used to key network and application layer security services between arbitrary hosts in the domain pair. Many managers of large-scale distributed systems would love a scalable, distributed keying infrastructure--the DNSsec-enabled OpenSSH client is very useful :-). Even with a certification service starting at the root, such alternative models would still be very useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 21:38: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from crewsoft.com (ns.aenet.net [157.22.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 6485537B67D for ; Mon, 19 Feb 2001 21:38:01 -0800 (PST) Received: from [63.206.197.104] (account cberger@wireless-networks.com HELO wireless-networks.com) by crewsoft.com (CommuniGate Pro SMTP 3.4b8) with ESMTP id 491662; Mon, 19 Feb 2001 21:40:46 -0800 Message-ID: <3A920302.D750332F@wireless-networks.com> Date: Mon, 19 Feb 2001 21:39:14 -0800 From: Cedric Berger X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200227.f1K2RHv02933@cwsys.cwsent.com> <3A9200C6.AA3C8433@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Configuration data > on VMS was mostly stored in the form of "logical names", which are sort > of like persistent environment variables with different namespaces (per > system, per group, and per user). Well, the windows registry also provide such kind of centralized, persistent environment variables, with different namespaces (per system, per user)? At least, let's say that Windows way of storing configuration looks closer then VMS than UNIX. Cedric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 22: 2:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id B44D937B491 for ; Mon, 19 Feb 2001 22:02:48 -0800 (PST) Received: (qmail 19156 invoked from network); 16 Feb 2001 21:02:46 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 16 Feb 2001 21:02:46 -0000 Message-ID: <3A8D9576.C9AC3045@integratus.com> Date: Fri, 16 Feb 2001 13:02:46 -0800 From: Jack Rusher Organization: http://www.integratus.com/ X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Lyndon Nerenberg , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > -r-sr-sr-x 1 uucp dialer - 124400 Jan 31 20:21 /usr/bin/cu* > -r-xr-xr-x 1 uucp dialer - 37980 Jan 31 20:27 /usr/bin/tip* ...which brings up the point that these two utilities are enormously useful when you want to communicate with devices that are connected via serial ports. cu(1) is my preferred tool for attaching to serial consoles with my laptop. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 22:30:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3CAB637B491 for ; Mon, 19 Feb 2001 22:30:09 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14V5d5-0000ok-00; Mon, 19 Feb 2001 22:46:27 -0700 Message-ID: <3A9204B3.B4FA5B88@softweyr.com> Date: Mon, 19 Feb 2001 22:46:27 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Dan Peterson , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200103.SAA04042@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > > > but you can't share your fixes with anyone else. > > > > http://www.djbdns.org Been there, read that, understand the part that says I can't modify tinydns to do what I need it to and then sell or even give it to my customers. What part of this do you NOT understand? > Unfortunately, I still can't sell my company, if I patch DJBDNS, and > my company relies upon it, since I will be in violation of the license. ^^^^^^^^^^^^^^^^^^^^^^^^ > > > Dynamic DNS? > > > > I can't say I've ever used this. Sounds like another BIND klugde, though. It > > would probably be easier to write a simple script to edit your data file and > > rebuild data.cdb. RTFM at http://cr.yp.to/djbdns/tinydns-data.html . > > DNSUPDAT, which is the proper name of the facility, allows you to > make updates to zone data in the primary, without taking the server > down, and without an outage while the server reloads its file. In particular, in recent versions of BIND, you can do this via a LOCAL library, and is supported in recent versions of DHCP from ISC. The two work together to form a very effective way to introduce workstation names into the DNS zone as they are given DHCP leases. Yes, we need this, no tinydns does not support them, and no, you can't make it support them and distribute the code without violating DJB's license. ^^^^^^^^^^^^^^^^^^^^^^^ > > > DNSSEC? > > > > http://cr.yp.to/djbdns/forgery.html Right, this is his justification for not providing DNSSEC. I have control over the machines that will be communicating with my server, and can verify that to a degree that meets my needs. So, what we are left with is YET AGAIN software that doesn't meet my needs, and cannot be made to meet my needs AND be distributed to anyone else without violating the license. ^^^^^^^^^^^^^^^^^^^^^ > This is substantially incorrect. His reading is based on trusting > an exterior zone on the basis of trusting a signature authority; > if, on thge other hand, you want to establish your own security > associations internally, perhaps going so far as to establish > exterior associations with other companies for whom you have a > record of their public keys, you can do so. > Also, it is out of date: NSI has stated an intent to start signing, > as soon as the RFC goes standard. Other authoritative zone servers may do the same. Mine, for instance. DJB's analysis is valid as far as it goes, but mostly just refuses to address the issue because DJB doesn't think it's necessary. That's fine, but the rest of the world is marching on and making it work, in the mean- time we can't even update tinydns to do so unless we violate DJB's license. ^^^^^^^^^^^^^^^^^^^^^ > Meanwhile, there's still the license. I hope you're all finally starting to pick up on the "you can't do that without VIOLATING DJB's LICENSE" part here, it seems to be echoing quite loudly in this thread. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 22:53: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2F49137B401 for ; Mon, 19 Feb 2001 22:53:06 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1K6qnw40602; Mon, 19 Feb 2001 22:52:49 -0800 (PST) (envelope-from dillon) Date: Mon, 19 Feb 2001 22:52:49 -0800 (PST) From: Matt Dillon Message-Id: <200102200652.f1K6qnw40602@earth.backplane.com> To: Terry Lambert Cc: bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200251.TAA06099@usr05.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :to the unaltered DJBDNS code, since the binaries of the modified :> :code themselves are not permitted to be redistributed. :> :> It means nothing of the sort. Unless DJBDNS explicitly says that :> a change of ownership (company bought, merger,... ) requires doing :> the above very silly thing, there is no legal risk whatsoever. :> A company being sold to another company is a very, very, very :> different beast then a company selling software commercially. : :Selling the company transfers ownership of the binaries. : : : Terry Lambert : terry@lambert.org Look Terry, I went through one of those damn aquisitions... AND a merger, with BEST. I know you really want to make a mountain out of a molehill but all you are doing here is creating confusion over a non-issue. It is unnecessary. There is no problem here and there never was. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 19 23: 7: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 6D8F337B684 for ; Mon, 19 Feb 2001 23:06:51 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14V6YY-0000qW-00; Mon, 19 Feb 2001 23:45:50 -0700 Message-ID: <3A92129E.7CD722F4@softweyr.com> Date: Mon, 19 Feb 2001 23:45:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Cedric Berger Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200227.f1K2RHv02933@cwsys.cwsent.com> <3A9200C6.AA3C8433@softweyr.com> <3A920302.D750332F@wireless-networks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cedric Berger wrote: > > > Configuration data > > on VMS was mostly stored in the form of "logical names", which are sort > > of like persistent environment variables with different namespaces (per > > system, per group, and per user). > > Well, the windows registry also provide such kind of centralized, > persistent environment variables, with different namespaces > (per system, per user)? > > At least, let's say that Windows way of storing configuration looks > closer then VMS than UNIX. OK, except VMS didn't store them in some half-baked database file, and didn't regularly scramble all of it. ;^) The logicals on VMS were stored only in memory, and were created during or after system boot by DSL procedures, the equivalent of shell scripts. This is actually much more like UNIX than the Windows Registry. Side Note: last week, my wife's computer would no longer hotsync either of our Handspring Visors. An email to tech support resulted in a reply with instructions to remove a corrupted key from the Registry; both Visors immediately hotsynced following this surgery. What an unreliable pile of crap. Could we please get the AvantGo pipeline for FreeBSD, so I can download Daily DaemonNews into my Visor from a REAL computer? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 0:49:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C0EC837B67D for ; Tue, 20 Feb 2001 00:49:25 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14V6Zc-00083O-00; Tue, 20 Feb 2001 06:46:56 +0000 Date: Tue, 20 Feb 2001 06:46:56 +0000 From: Tony Finch To: Peter Pentchev Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010220064656.T2746@hand.dotat.at> References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com> <20010219123015.D2946@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010219123015.D2946@ringworld.oblivion.bg> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > >tinydns never loads its datafile into memory, it mmap's it and does >one-pass lookups on each and every query. That implies O(N) lookups for queries which is too insane even for DJB. Surely it must be able to handle large zonefiles? Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at ROCKALL MALIN: SOUTHWESTERLY 4 OR 5, VEERING NORTHWESTERLY 3 OR 4 IN NORTH. RAIN OR DRIZZLE. GOOD BECOMING MODERATE OR POOR. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 0:53: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 871A237B491 for ; Tue, 20 Feb 2001 00:52:57 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CB64366B09; Tue, 20 Feb 2001 00:52:56 -0800 (PST) Date: Tue, 20 Feb 2001 00:52:56 -0800 From: Kris Kennaway To: Dan Peterson Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010220005256.A21695@mollari.cthul.hu> References: <20010219101234.A98114@danp.net> <20010219104338.B98114@danp.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010219104338.B98114@danp.net>; from danp@danp.net on Mon, Feb 19, 2001 at 10:43:38AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Guys, this thread is off-topic for -arch ("discussions of FreeBSD architecture"). DJBDNS will not be imported into FreeBSD for reasons already given, so discussions of DJBDNS vs BIND should go to -chat. Thanks, Kris --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kjBoWry0BWjoQKURAsg/AJ9RP0X2yHp9efbf8nGbBzv++mq5kgCfX+Ia SYwL8EwOZaJNnIt8vupKpi8= =OhiH -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 1: 1:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rapier.smartspace.co.za (rapier.smartspace.co.za [66.8.25.34]) by hub.freebsd.org (Postfix) with SMTP id A8B0637B401 for ; Tue, 20 Feb 2001 01:01:31 -0800 (PST) (envelope-from nbm@rapier.smartspace.co.za) Received: (qmail 18802 invoked by uid 1001); 20 Feb 2001 09:01:10 -0000 Date: Tue, 20 Feb 2001 11:01:10 +0200 From: Neil Blakey-Milner To: Tony Finch Cc: Peter Pentchev , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010220110110.A18247@rapier.smartspace.co.za> References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com> <20010219123015.D2946@ringworld.oblivion.bg> <20010220064656.T2746@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220064656.T2746@hand.dotat.at>; from dot@dotat.at on Tue, Feb 20, 2001 at 06:46:56AM +0000 Organization: Building Intelligence X-Operating-System: FreeBSD 4.2-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue 2001-02-20 (06:46), Tony Finch wrote: > Peter Pentchev wrote: > > > >tinydns never loads its datafile into memory, it mmap's it and does > >one-pass lookups on each and every query. > > That implies O(N) lookups for queries which is too insane even for > DJB. Surely it must be able to handle large zonefiles? It uses CDB. It needs just two disk accesses to return an entry stored therein (or just one, if the entry doesn't exist). Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 1:15:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 759DF37B401 for ; Tue, 20 Feb 2001 01:15:49 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 199F666B09; Tue, 20 Feb 2001 01:15:48 -0800 (PST) Date: Tue, 20 Feb 2001 01:15:48 -0800 From: Kris Kennaway To: arch@freebsd.org Subject: [cgd@netbsd.org: CVS commit: basesrc] Message-ID: <20010220011548.A34873@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What does this list think about the merits of this idea? Kris ----- Forwarded message from "Chris G. Demetriou" ----- Delivered-To: kkenn@localhost.obsecurity.org Delivered-To: kris@freebsd.org Delivered-To: source-changes@netbsd.org From: "Chris G. Demetriou" Subject: CVS commit: basesrc To: source-changes@netbsd.org Reply-To: cgd@netbsd.org Date: Tue, 20 Feb 2001 00:13:23 +0200 (EET) Precedence: list X-UIDL: 765b2d66d1c210d4309e91f0561210ff Module Name: basesrc Committed By: cgd Date: Mon Feb 19 22:13:23 UTC 2001 Added Files: basesrc/lib/libc/gen: getprogname.3 getprogname.c setprogname.c Log Message: add getprogname() and setprogname(). These allow uses of __progname to be wrapped in some sane fashion, for portability. To generate a diff of this commit: cvs rdiff -r0 -r1.1 basesrc/lib/libc/gen/getprogname.3 \ basesrc/lib/libc/gen/getprogname.c basesrc/lib/libc/gen/setprogname.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ----- End forwarded message ----- --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kjXEWry0BWjoQKURAsfDAKC7A1lsuQ3Qwq082vGi7m9JVlRGCwCdF4P4 5IvNP8r+wdHI/p6ibQuzoTE= =Bse4 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 2: 5: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id E23E237B4EC for ; Tue, 20 Feb 2001 02:05:02 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14V9f3-0009PQ-00; Tue, 20 Feb 2001 10:04:45 +0000 Date: Tue, 20 Feb 2001 10:04:45 +0000 From: Tony Finch To: Jordan Hubbard Cc: arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <20010220100445.A35619@hand.dotat.at> References: <200102170732.f1H7WS952157@gratis.grondar.za> <2628.982402377@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2628.982402377@winston.osd.bsdi.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > >In a design like this, all distinction between src and ports goes away >and it largely comes down to how much source the user wants to have >lying around - anything from all to none. This whole thing -- splitting the OS up into a bunch of small independently-selectable packages -- sounds exactly like the way Debian works, except I expect FreeBSD would have more emphasis on using a revision control system for at least the core components rather than a ports-like collection of random patches. My introduction [1] to free unices was Debian. The main problem I had with it was that the two-and-two-halves-level organization of the packages was too broad. I say two-and-two-halves because it is similar to the ports two-level organization of category/port but with a big split based on the degree of freedom in the licence, and with a second "priority" attribute that determines how core the package is. The ports collection has the same problem -- too much stuff to wade through. When installing the core OS being presented with N thousand components to choose from is not good. Yes, this is a user-interface issue, and concentrating more on the forest given by the priority attribute at installation time rather than all the trees of the packages is a better approach. I note that one thing the ports has that IIRC Debian doesn't have the idea of a package being in more than one category; this is useful because it can then subsume the priority attribute, e.g. sh would be in "core" and "shells" but bash is just in "shells". With an appropriate user interface you can also then say "show me all X11 text editors" etc. Another problem with Debian is their very slow release cycle. This is partly due to lack of discipline but also due to size: they have more developers and more packages, and they also require that a much larger proportion of the packages (essentially every GPLed/BSDed/MITed Linux/Unix/X tool) are up to the same standard in order to do a release. And their lack of a central CVS repository means that the release engineer or whoever cannot fix an errant package without seriously inconveniencing the package's maintainer. [1] five years ago, to give you an idea of how stale my information is Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at GERMAN BIGHT: NORTHWESTERLY 5 OR 6. RAIN LATER. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 2:30:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 3C30A37B69D for ; Tue, 20 Feb 2001 02:30:28 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14VA3s-0009TA-00; Tue, 20 Feb 2001 10:30:24 +0000 Date: Tue, 20 Feb 2001 10:30:24 +0000 From: Tony Finch To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] Message-ID: <20010220103024.B35619@hand.dotat.at> References: <20010220011548.A34873@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220011548.A34873@mollari.cthul.hu> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: >What does this list think about the merits of this idea? For someone who likes to use bits of FreeBSD (e.g. err(3) etc.) in random software that runs on other OSs, this sounds like a thoroughly good thing to me :-) Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at GERMAN BIGHT: NORTHWESTERLY 5 OR 6. RAIN LATER. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 2:51:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id EA91B37B401 for ; Tue, 20 Feb 2001 02:51:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id DAA24099; Tue, 20 Feb 2001 03:45:44 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAMRaWdV; Tue Feb 20 03:45:43 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA14037; Tue, 20 Feb 2001 03:51:53 -0700 (MST) From: Terry Lambert Message-Id: <200102201051.DAA14037@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 20 Feb 2001 10:51:53 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <200102200652.f1K6qnw40602@earth.backplane.com> from "Matt Dillon" at Feb 19, 2001 10:52:49 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Look Terry, I went through one of those damn aquisitions... AND a merger, > with BEST. I know you really want to make a mountain out of a molehill > but all you are doing here is creating confusion over a non-issue. It is > unnecessary. There is no problem here and there never was. I wish you would quit fixating on BEST, since I pointed out that the license had changed, and the risk only existed for the old license. I went through IBMs acquisition of Whistle: a 6 month+ due dilligence process, which resulted in us getting rid of some code that we had planned to ship on the next InterJet software release, due to IBMs belief it was infringing on their patents, and was distributed under the GPL, which they believed could be construed as a royalty free license for anyone to use the patents involved, should they demand source code. I am only talking about what lawyers view as risk. Acceptability of any given risk is a business decision, and one that people shouldn't be forced into simply by electing to use FreeBSD. For FreeBSD itself, the biggest risk the lawyers saw was Poul's "BeerWare" license, FWIW. The main take aways from this discussion should be that FreeBSD needs to be careful of the licenses on the code it lets into its tree (as it _was_ with the Soft Updates code, under the old license), and that FreeBSD, philosophically, as a group, isn't going to be easily talked away from that position, if ever. 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 2:58:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id BE8F737B491 for ; Tue, 20 Feb 2001 02:58:41 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id DAA25219; Tue, 20 Feb 2001 03:52:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAx_aioX; Tue Feb 20 03:52:26 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA14109; Tue, 20 Feb 2001 03:58:36 -0700 (MST) From: Terry Lambert Message-Id: <200102201058.DAA14109@usr05.primenet.com> Subject: Re: Moving Things [was Re: List of things to move from main tree] To: dot@dotat.at (Tony Finch) Date: Tue, 20 Feb 2001 10:58:35 +0000 (GMT) Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <20010220100445.A35619@hand.dotat.at> from "Tony Finch" at Feb 20, 2001 10:04:45 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This whole thing -- splitting the OS up into a bunch of small > independently-selectable packages -- sounds exactly like the way > Debian works, except I expect FreeBSD would have more emphasis on > using a revision control system for at least the core components > rather than a ports-like collection of random patches. An important point in configuration management, which SCO and Solaris, et. al. have addressed, but which has so far been missing from this discussion is the "binary upgrade" scenario; I think one of the primary design goals has to be, if not to support it, at least to not preclude it being supported later. A nice-to-have would be the ability to "save" the state of a machine, as in "as this machine is currently configured". This probably would exclude configuration data, and be limited to just what was installed. A centralized configuration store would let you include configuration data, which would be potentially impossible otherwise. I expect that you would want to not include IP address or machine name or other per machine static data, but you might include "boots to a KDE login screen" or "uses DHCP to get an IP address". I can't see that being possible, given arbitrary configurations files in arbitrary locations all over the firmament. 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 3: 2: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id D1FB037B401; Tue, 20 Feb 2001 03:01:55 -0800 (PST) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp8.dyn248.pacific.net.au [203.143.248.8]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id WAA00262; Tue, 20 Feb 2001 22:01:53 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.11.1) with ESMTP id f1KB3VC19818; Tue, 20 Feb 2001 21:03:31 +1000 (EST) (envelope-from mckay) Message-Id: <200102201103.f1KB3VC19818@dungeon.home> To: Warner Losh Cc: Stephen McKay , arch@freebsd.org Subject: Re: The whole libc thing. References: <200102191217.f1JCHno13825@dungeon.home> <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> <200102191734.f1JHYQW61198@harmony.village.org> In-Reply-To: <200102191734.f1JHYQW61198@harmony.village.org> from Warner Losh at "Mon, 19 Feb 2001 10:34:26 -0700" Date: Tue, 20 Feb 2001 21:03:31 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 19th February 2001, Warner Losh wrote: >In message <200102191217.f1JCHno13825@dungeon.home> Stephen McKay writes: >: >Case 3. I've installed a port that installs libfred.so.3 from 4.2 >: >release. It contains __sF references. I have a binary (say barney) >: >that links libfred.so.3 and libc.so.4. Things work now. I rebuild >: >the world. Things still work because neither of the above has >: >changed. Now let's say I want to build wilma that depends on libfred. >: >When wilma is built, it will fail to run because it links against >: >libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so >: >it will fail at link time or run time. This is easy to fix. Just >: >rebuild the port tht produced libfred.so.3. A new libfred.so.3 is >: >installed. wilma will now run (maybe after being rebuilt). barney >: >will also still run because it gets all the symbols it needs >: >(including the new libfred.so.3). >: >: Doesn't barney die due to unresolved references to __stdout (etc) from >: the recompiled libfred.so.3? It only has the old libc.so.4 to help it. >: Or are you proposing to regenerate all libc.so.* back to the ELF >: transition? I am still confused, and still concerned, and still >: think a global major version bump is unavoidable. > >I am saying that we regenerate libc.so.[34]. barney then wouldn't die >from the missing symbol and life would be good, assuming that no >macros used _up, which I'm nearly positive none do. There have never been macros that use _up, and I can't see any reason for nasty FILE-grovelling programs to use _up. Should be safe. >We've added >symbols like this in the past for various reasons, but maybe never so >late in the 3.x branch. We also have the technology to regenerate the >libc.so.[34] in place if we needed to w/o recompiling, but polishing >it for the great masses will take some time. Ah, I see. You fix the problem by fixing all copies of libc, which in this case is really just two versions. This has two interesting results: people who don't upgrade anything at all can enjoy their ignorance in peace, and those who upgrade something causing it to break, can be told to install a compatible hacked libc, which fixes their current problem and all future problems (to do with FILE). But that only gets you through part one. When part two (FILE becomes radically incompatible) arrives, what then? Old binaries and/or libraries will always want to see __sF, and will pass around pointers into __sF. Will libc forever after translate &__sF[1] to __stdout? How could it hope to support old binaries that fiddle with the insides of FILE? It can't. I predict that these binaries will be orphaned. >After talking with Peter on IRC extensively about this, I think that >we need a bigger window where we generate __stdout before trying to >take the plunge. There are still too many libraries that depend on >__sF. Do I read this as "keep the hack in place long enough so that every binary anyone cares about has been recompiled"? If so, I think this is going the wrong way. If we are going for a global recompile, it should be explicit, but not in a way that overwrites existing libraries. Oh, and earlier I forgot to highlight your comment: "This is easy to fix. Just rebuild the port that produced libfred.so.3." This implies that recompiling a lot of stuff is central to your plans. I claim that we can make this recompiling explicit and safe to all past and future binaries by equating this recompile with a major version bump. Everywhere. Lastly, I'm happy that urgent commits have slowed, and we can work this out at a more civilized pace. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 3:46:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 94FEF37B4EC for ; Tue, 20 Feb 2001 03:46:45 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3944766F23; Tue, 20 Feb 2001 03:46:45 -0800 (PST) Date: Tue, 20 Feb 2001 03:46:45 -0800 From: Kris Kennaway To: arch@freebsd.org Subject: fmtcheck() Message-ID: <20010220034644.A26123@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --neYutvxvOLaeuPCA Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm intending to import the fmtcheck() function from NetBSD, to aid in fixing format string bogons and potential vulnerabilities. I'd appreciate stylistic comments, especially about libc and mdoc magic which may need to be applied to the attached files. Kris --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: lib/libc/gen/Makefile.inc =================================================================== RCS file: /mnt/ncvs/src/lib/libc/gen/Makefile.inc,v retrieving revision 1.74 diff -u -r1.74 Makefile.inc --- lib/libc/gen/Makefile.inc 2001/02/05 14:55:14 1.74 +++ lib/libc/gen/Makefile.inc 2001/02/20 11:01:03 @@ -9,7 +9,7 @@ clock.c closedir.c confstr.c \ crypt.c ctermid.c daemon.c devname.c dirname.c disklabel.c \ dlfcn.c drand48.c erand48.c err.c errlst.c \ - exec.c fnmatch.c fstab.c ftok.c fts.c getbootfile.c getbsize.c \ + exec.c fmtcheck.c fnmatch.c fstab.c ftok.c fts.c getbootfile.c getbsize.c \ getcap.c getcwd.c getdomainname.c getgrent.c getgrouplist.c \ gethostname.c getloadavg.c getlogin.c getmntinfo.c getnetgrent.c \ getobjformat.c getosreldate.c getpagesize.c \ @@ -38,7 +38,7 @@ basename.3 \ confstr.3 ctermid.3 daemon.3 \ devname.3 directory.3 dirname.3 dladdr.3 dllockinit.3 dlopen.3 \ - err.3 exec.3 fnmatch.3 frexp.3 ftok.3 fts.3 \ + err.3 exec.3 fmtcheck.3 fnmatch.3 frexp.3 ftok.3 fts.3 \ getbootfile.3 getbsize.3 getcap.3 getcwd.3 \ getdiskbyname.3 getdomainname.3 getfsent.3 \ getgrent.3 getgrouplist.3 gethostname.3 getloadavg.3 \ Index: include/stdio.h =================================================================== RCS file: /mnt/ncvs/src/include/stdio.h,v retrieving revision 1.30 diff -u -r1.30 stdio.h --- include/stdio.h 2001/02/16 06:11:21 1.30 +++ include/stdio.h 2001/02/20 11:03:54 @@ -304,6 +304,8 @@ __BEGIN_DECLS int asprintf __P((char **, const char *, ...)) __printflike(2, 3); char *ctermid_r __P((char *)); +const char *fmtcheck __P((const char *, const char *)) + __attribute__((__format_arg__(2)));; char *fgetln __P((FILE *, size_t *)); int fpurge __P((FILE *)); int fseeko __P((FILE *, _BSD_OFF_T_, int)); --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fmtcheck.c" Content-Transfer-Encoding: quoted-printable /* $FreeBSD$ */ /* $NetBSD: fmtcheck.c,v 1.2 2000/11/01 01:17:20 briggs Exp $ */ /*- * Copyright (c) 2000 The NetBSD Foundation, Inc. * All rights reserved. * * This code was contributed to The NetBSD Foundation by Allen Briggs. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the NetBSD * Foundation, Inc. and its contributors. * 4. Neither the name of The NetBSD Foundation nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMI= TED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICUL= AR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF T= HE * POSSIBILITY OF SUCH DAMAGE. */ #include #ifndef lint static const char rcsid[] =3D "$FreeBSD$"; #endif /* not lint */ #include "namespace.h" #include #include #include #include #ifdef __weak_alias __weak_alias(fmtcheck,__fmtcheck) #endif enum __e_fmtcheck_types { FMTCHECK_START, FMTCHECK_SHORT, FMTCHECK_INT, FMTCHECK_LONG, FMTCHECK_QUAD, FMTCHECK_SHORTPOINTER, FMTCHECK_INTPOINTER, FMTCHECK_LONGPOINTER, FMTCHECK_QUADPOINTER, FMTCHECK_DOUBLE, FMTCHECK_LONGDOUBLE, FMTCHECK_STRING, FMTCHECK_WIDTH, FMTCHECK_PRECISION, FMTCHECK_DONE, FMTCHECK_UNKNOWN }; typedef enum __e_fmtcheck_types EFT; #define RETURN(pf,f,r) do { \ *(pf) =3D (f); \ return r; \ } /*NOTREACHED*/ /*CONSTCOND*/ while (0) static EFT get_next_format_from_precision(const char **pf) { int sh, lg, quad, longdouble; const char *f; sh =3D lg =3D quad =3D longdouble =3D 0; f =3D *pf; switch (*f) { case 'h': f++; sh =3D 1; break; case 'l': f++; if (!*f) RETURN(pf,f,FMTCHECK_UNKNOWN); if (*f =3D=3D 'l') { f++; quad =3D 1; } else { lg =3D 1; } break; case 'q': f++; quad =3D 1; break; case 'L': f++; longdouble =3D 1; break; default: break; } if (!*f) RETURN(pf,f,FMTCHECK_UNKNOWN); if (strchr("diouxX", *f)) { if (longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); if (lg) RETURN(pf,f,FMTCHECK_LONG); if (quad) RETURN(pf,f,FMTCHECK_QUAD); RETURN(pf,f,FMTCHECK_INT); } if (*f =3D=3D 'n') { if (longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); if (sh) RETURN(pf,f,FMTCHECK_SHORTPOINTER); if (lg) RETURN(pf,f,FMTCHECK_LONGPOINTER); if (quad) RETURN(pf,f,FMTCHECK_QUADPOINTER); RETURN(pf,f,FMTCHECK_INTPOINTER); } if (strchr("DOU", *f)) { if (sh + lg + quad + longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); RETURN(pf,f,FMTCHECK_LONG); } if (strchr("eEfg", *f)) { if (longdouble) RETURN(pf,f,FMTCHECK_LONGDOUBLE); if (sh + lg + quad) RETURN(pf,f,FMTCHECK_UNKNOWN); RETURN(pf,f,FMTCHECK_DOUBLE); } if (*f =3D=3D 'c') { if (sh + lg + quad + longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); RETURN(pf,f,FMTCHECK_INT); } if (*f =3D=3D 's') { if (sh + lg + quad + longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); RETURN(pf,f,FMTCHECK_STRING); } if (*f =3D=3D 'p') { if (sh + lg + quad + longdouble) RETURN(pf,f,FMTCHECK_UNKNOWN); RETURN(pf,f,FMTCHECK_LONG); } RETURN(pf,f,FMTCHECK_UNKNOWN); /*NOTREACHED*/ } static EFT get_next_format_from_width(const char **pf) { const char *f; f =3D *pf; if (*f =3D=3D '.') { f++; if (*f =3D=3D '*') { RETURN(pf,f,FMTCHECK_PRECISION); } /* eat any precision (empty is allowed) */ while (isdigit(*f)) f++; if (!*f) RETURN(pf,f,FMTCHECK_UNKNOWN); } RETURN(pf,f,get_next_format_from_precision(pf)); /*NOTREACHED*/ } static EFT get_next_format(const char **pf, EFT eft) { int infmt; const char *f; if (eft =3D=3D FMTCHECK_WIDTH) { (*pf)++; return get_next_format_from_width(pf); } else if (eft =3D=3D FMTCHECK_PRECISION) { (*pf)++; return get_next_format_from_precision(pf); } f =3D *pf; infmt =3D 0; while (!infmt) { f =3D strchr(f, '%'); if (f =3D=3D NULL) RETURN(pf,f,FMTCHECK_DONE); f++; if (!*f) RETURN(pf,f,FMTCHECK_UNKNOWN); if (*f !=3D '%') infmt =3D 1; else f++; } /* Eat any of the flags */ while (*f && (strchr("#0- +", *f))) f++; if (*f =3D=3D '*') { RETURN(pf,f,FMTCHECK_WIDTH); } /* eat any width */ while (isdigit(*f)) f++; if (!*f) { RETURN(pf,f,FMTCHECK_UNKNOWN); } RETURN(pf,f,get_next_format_from_width(pf)); /*NOTREACHED*/ } __const char * fmtcheck(const char *f1, const char *f2) { const char *f1p, *f2p; EFT f1t, f2t; if (!f1) return f2; =09 f1p =3D f1; f1t =3D FMTCHECK_START; f2p =3D f2; f2t =3D FMTCHECK_START; while ((f1t =3D get_next_format(&f1p, f1t)) !=3D FMTCHECK_DONE) { if (f1t =3D=3D FMTCHECK_UNKNOWN) return f2; f2t =3D get_next_format(&f2p, f2t); if (f1t !=3D f2t) return f2; } return f1; } --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fmtcheck.3" .\" $NetBSD$ .\" .\" Copyright (c) 2000 The NetBSD Foundation, Inc. .\" All rights reserved. .\" .\" This file was contributed to The NetBSD Foundation by Allen Briggs. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the NetBSD .\" Foundation, Inc. and its contributors. .\" 4. Neither the name of The NetBSD Foundation nor the names of its .\" contributors may be used to endorse or promote products derived .\" from this software without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\" POSSIBILITY OF SUCH DAMAGE. .\" .Dd October 17, 2000 .Os .Dt FMTCHECK 3 .Sh NAME .Nm fmtcheck .Nd sanitizes user-supplied printf(3)-style format string .Sh LIBRARY .Lb libc .Sh SYNOPSIS .Fd #include .Ft const char * .Fn fmtcheck "const char *fmt_suspect" "const char *fmt_default" .Sh DESCRIPTION The .Nm function scans .Fa fmt_suspect and .Fa fmt_default to determine if .Fa fmt_suspect will consume the same argument types as .Fa fmt_default and to ensure that .Fa fmt_suspect is a valid format string. .Pp The .Xr printf 3 family of functions can not verify the types of arguments that they are passed at run-time. In some cases, like .Xr catgets 3 , it is useful or necessary to use a user-supplied format string with no guarantee that the format string matches the specified parameters. .Pp The .Nm function was designed to be used in these cases, as in: .Bd -literal -offset indent printf(fmtcheck(user_format, standard_format), arg1, arg2); .Ed .Pp In the check, field widths, fillers, precisions, etc. are ignored (unless the field width or precision is an asterisk .Ql * instead of a digit string). Also, any text other than the format specifiers is completely ignored. .Pp Note that the formats may be quite different as long as they accept the same parameters. For example, ".Dq %p %o %30s %#llx %-10.*e %n" is compatible with "This number %lu %d%% and string %s has %qd numbers and %.*g floats (%n)." However, "%o" is not equivalent to "%lx" because the first requires an integer and the second requires a long. .Sh RETURN VALUES If .Fa fmt_suspect is a valid format and consumes the same argument types as .Fa fmt_default , then the .Nm function will return .Fa fmt_suspect . Otherwise, it will return .Fa fmt_default . .Sh SEE ALSO .Xr printf 3 --x+6KMIRAuhnl3hBn-- --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6klkjWry0BWjoQKURAlLCAKDbRbCcj1FATDklar6Pkp7oxn4VwACdE7Y4 q1UIgUf5mLFt6c+ywmelNaQ= =Cq52 -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 3:59:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4607237B491 for ; Tue, 20 Feb 2001 03:59:54 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14VBSC-0009kq-00; Tue, 20 Feb 2001 11:59:36 +0000 Date: Tue, 20 Feb 2001 11:59:36 +0000 From: Tony Finch To: Terry Lambert Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010220115936.E35619@hand.dotat.at> References: <200102200652.f1K6qnw40602@earth.backplane.com> <200102201051.DAA14037@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102201051.DAA14037@usr05.primenet.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > >I wish you would quit fixating on BEST, since I pointed out that >the license had changed, and the risk only existed for the old >license. I would have thought that since BEST paid Kirk a licence fee for using softupdates that the old public licence terms are irrelevant since BEST had paid for a private licence. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at SOUTHWEST FORTIES CROMARTY FORTH: WEST VEERING NORTHWEST 4 OR 5 OCCASIONALLY 6. OCCASIONAL RAIN. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 7:47:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id B6C8E37B503; Tue, 20 Feb 2001 07:47:46 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f1KF7ti03710; Tue, 20 Feb 2001 15:07:55 GMT (envelope-from nik) Date: Tue, 20 Feb 2001 15:07:55 +0000 From: Nik Clayton To: Jack Rusher Cc: Robert Watson , Lyndon Nerenberg , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010220150755.A3696@canyon.nothing-going-on.org> References: <3A8D9576.C9AC3045@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A8D9576.C9AC3045@integratus.com>; from jar@integratus.com on Fri, Feb 16, 2001 at 01:02:46PM -0800 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 01:02:46PM -0800, Jack Rusher wrote: > Robert Watson wrote: > > > > -r-sr-sr-x 1 uucp dialer - 124400 Jan 31 20:21 /usr/bin/cu* > > -r-xr-xr-x 1 uucp dialer - 37980 Jan 31 20:27 /usr/bin/tip* > > ...which brings up the point that these two utilities are enormously > useful when you want to communicate with devices that are connected via > serial ports. cu(1) is my preferred tool for attaching to serial > consoles with my laptop. Speaking of which, any objections if I commit the following to the end of /etc/remote? com1:dv=/dev/cuaa0:br#115200:pa=none: com2:dv=/dev/cuaa1:br#115200:pa=none: com3:dv=/dev/cuaa2:br#115200:pa=none: com4:dv=/dev/cuaa3:br#115200:pa=none: N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 8:12:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 14FC537B401 for ; Tue, 20 Feb 2001 08:12:45 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14VFVt-00009e-00; Tue, 20 Feb 2001 09:19:41 -0700 Message-ID: <3A92991D.F4669C23@softweyr.com> Date: Tue, 20 Feb 2001 09:19:41 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Tony Finch , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <200102201058.DAA14109@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > This whole thing -- splitting the OS up into a bunch of small > > independently-selectable packages -- sounds exactly like the way > > Debian works, except I expect FreeBSD would have more emphasis on > > using a revision control system for at least the core components > > rather than a ports-like collection of random patches. > > An important point in configuration management, which SCO and > Solaris, et. al. have addressed, but which has so far been > missing from this discussion is the "binary upgrade" scenario; > I think one of the primary design goals has to be, if not to > support it, at least to not preclude it being supported later. > > A nice-to-have would be the ability to "save" the state of a > machine, as in "as this machine is currently configured". This > probably would exclude configuration data, and be limited to > just what was installed. A centralized configuration store > would let you include configuration data, which would be > potentially impossible otherwise. I expect that you would want > to not include IP address or machine name or other per machine > static data, but you might include "boots to a KDE login screen" > or "uses DHCP to get an IP address". I can't see that being > possible, given arbitrary configurations files in arbitrary > locations all over the firmament. We came to that same conclusion at DoBox, and finally settled on a technology for our "Registry" (for lack of a better description). We stuff PostgreSQL in every box. ;^) The price and the license is right, and it integrates rather nicely with web UI tools. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 8:18:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id BC9CC37B401; Tue, 20 Feb 2001 08:18:06 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.9.3/8.9.3) id LAA90079; Tue, 20 Feb 2001 11:17:59 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Tue, 20 Feb 2001 11:17:59 -0500 From: Will Andrews To: Nik Clayton Cc: Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010220111759.A83214@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , Nik Clayton , Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@FreeBSD.ORG References: <3A8D9576.C9AC3045@integratus.com> <20010220150755.A3696@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="hblleJHDxiLJUoyx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220150755.A3696@canyon.nothing-going-on.org>; from nik@FreeBSD.ORG on Tue, Feb 20, 2001 at 03:07:55PM +0000 X-Operating-System: FreeBSD 4.1-RELEASE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --hblleJHDxiLJUoyx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2001 at 03:07:55PM +0000, Nik Clayton wrote: > com1:dv=3D/dev/cuaa0:br#115200:pa=3Dnone: > com2:dv=3D/dev/cuaa1:br#115200:pa=3Dnone: > com3:dv=3D/dev/cuaa2:br#115200:pa=3Dnone: > com4:dv=3D/dev/cuaa3:br#115200:pa=3Dnone: Yes. Not everything supports 115200bps communication. --=20 wca --hblleJHDxiLJUoyx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kpi2F47idPgWcsURAvpeAJ9vR6QHaI877O0WUy9uXFYhcmkYTwCfe2O/ wIdpgNKPEQ7okrbypd+OZ5A= =ET8s -----END PGP SIGNATURE----- --hblleJHDxiLJUoyx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 8:31:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 3FB3A37B401 for ; Tue, 20 Feb 2001 08:31:12 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152CZ6DP; Tue, 20 Feb 2001 11:31:18 -0500 Reply-To: Randell Jesup To: Terry Lambert Cc: dillon@earth.backplane.com (Matt Dillon), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> From: Randell Jesup Date: 20 Feb 2001 11:31:52 -0500 In-Reply-To: Terry Lambert's message of "Tue, 20 Feb 2001 01:22:53 +0000 (GMT)" Message-ID: 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: >> :> cached state data is inherently bad everywhere, not just in DNS >> :> servers. >> : >> :You scare me, I was thinking just the same thing about mountd >> :earlier today. Only problem is that it violates POLA(* heh), one >> :could offer an command line option to have it watch the file. >> >> I was thinking just having a 'mountd -reload'. I don't like the >> idea of programs polling configuration files. I actually used a >> similar mechanism in Diablo and wound up having to add hacks to, >> for example, try to avoid catching a configuration file in the middle >> of being written out by an editor. >> >> A better way would be to take the 'vipw' concept and write a general >> system utility to edit configuration files that does the right thing >> when you write the config file out (heh heh... based on.... another >> config file!). > >You could close the file in between polls, and reopen it O_EXCL; >or your vipw suggestion would also work, using a two stage commit >to ensure that it was all or nothing for changes. > >Really, the program wants to sit on the file as part of its select >loop, and when the file is closed so that it's the sole opener again, >get an "exceptional condition" flagged in the select. > >Barring that, the next best thing is a signal, and the next best >after that is a poll. As an aside, we ran into this in AmigaDos as well. We cached all of our preferences (configuration) data in ramdisk files (which hardly took any space, since there was no block overhead, and guaranteed fast access). I then added notification commands to the filesystem, so applications could find out when the configuration changed. For fixed-size (binary) config files, you could simply make a single read, which became a ram-to-ram copy without very much overhead. For variable-sized files, a simple exclusive open and then read would do. Since these were all ram-to-ram copies, and the overhead on the Amiga of message passing and Open()/Read() was small, it worked well. >In an ideal system, you would change the host name one place (for an >example of commonly cached information), and everything would "just >know" and "just do the right thing". There's still a synchronization problem, even if the hostname is in shared memory, even if the write is atomic (a reader may be in the middle of reading the string). >Having an external program watching the configuration file changes >is really a very poor approach, since it doesn't address the >underlying problem very well. True. >A registry-like configuration store, which was cached by the OS, >and was referenced directly each time the data was needed, instead >of allowing the programs to cache data which might change would >really be the best approach, Fetching the data out of a kernel service on each access would be (potentially) a pretty major hit, performance-wise. Some form of registration of interest in the data would be better. Either something like the Amiga (get a signal/message/callback/whatever when it changes, then request the new information), or something that passes the notification along with the new data. The downside is that to change the data, you must also go through this procedure. The nice thing about the Amiga notification method was that you could use any tool to modify a preference (configuration option) - text editors, fancy GUI editors, copy (cp), etc. You could still provide this behavior if you made this configuration cache also act as a virtual FS, so you could call up (say) /config/hostname into vi, change it, then just save it. Or just copy another file over the existing one, etc. This kindof turns vipw on it's head. An alternative would be to leave everything in normal files, extend the vipw schema to lock arbitrary files (configedit), and then hook it into a notification method as per above. This loses the ability to use something like cp, but it allows arbitrary text editors, and hooks can be given to allow GUI programs to interact with a config file as well. > but I rather think that it would be >rejected because Microsoft had the idea. Heh. A new way to screw >over your competitors: make them so hateful that they refuse to >learn from your good ideas, and have to come up with something >gratuitously different (and probably more complicated) just to be >able to say that they aren't like you... :-) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 8:58:43 2001 Delivered-To: freebsd-arch@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 CB5BE37B684 for ; Tue, 20 Feb 2001 08:58:38 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1KGvNm45675; Tue, 20 Feb 2001 10:57:23 -0600 (CST) (envelope-from jlemon) Date: Tue, 20 Feb 2001 10:57:23 -0600 From: Jonathan Lemon To: Randell Jesup Cc: Terry Lambert , Matt Dillon , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010220105723.C85542@prism.flugsvamp.com> References: <200102200122.SAA04466@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 11:31:52AM -0500, Randell Jesup wrote: > Fetching the data out of a kernel service on each access would be > (potentially) a pretty major hit, performance-wise. Some form of > registration of interest in the data would be better. Either something > like the Amiga (get a signal/message/callback/whatever when it changes, > then request the new information), or something that passes the > notification along with the new data. It would be fairly trivial to monitor a configuration file with kevent, which would generate a notice whenever the file is changed/copied/renamed, etc. I believe that John-Mark Gurney had patches somewhere to implement exactly this for inetd. The problem is that under our current model, the administrators do not expect writes to the file to take immediate effect, and this immediately breaks POLA. So while it could be done, it may not be a good idea. At the very least, I would argue that it should be hidden behind a flag option. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 10: 3:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 0A29537B4EC for ; Tue, 20 Feb 2001 10:03:24 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id TAA14716 for arch@FreeBSD.ORG; Tue, 20 Feb 2001 19:03:21 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 749E08811; Tue, 20 Feb 2001 13:40:13 +0100 (CET) Date: Tue, 20 Feb 2001 13:40:13 +0100 From: Ollivier Robert To: arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010220134013.A84722@keltia.freenix.fr> Mail-Followup-To: Ollivier Robert , arch@FreeBSD.ORG References: <200102170722.f1H7MHm20405@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:22:17PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Matt Dillon: > There are fewer people screaming for UUCP to stay in the base tree > then, say, people screaming for rlogind to stay in the base tree. > Despite Terry's waxing poetic about UUCP's dialup capabilities, > every soul I know (except maybe Terry) who has ever used UUCP in the > past no longer does (and I should know: I wrote AmigaUUCP!). Don't forget that the USA are not alone. UUCP is still used in Europe where comms are more expensive. Another point: when fetchmail (or anything POP3/IMAP4 based) grows a decent multi-domain / multiusers support, we may consider removing it. I use it daily over TCP and having multiple domains and multiple users is trivial compared to what you have to do with fetchmail for that. > However, if those people are going to make a big deal about it, > I suppose we can take the intermediate step of having a BUILD_UUCP > make.conf (opt-in) option for the next few years. I could accept that but don't remove it please. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 10: 4:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 5B3CD37B401 for ; Tue, 20 Feb 2001 10:04:29 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1KI4HG45260; Tue, 20 Feb 2001 10:04:17 -0800 (PST) (envelope-from dillon) Date: Tue, 20 Feb 2001 10:04:17 -0800 (PST) From: Matt Dillon Message-Id: <200102201804.f1KI4HG45260@earth.backplane.com> To: Jonathan Lemon Cc: Randell Jesup , Terry Lambert , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> <20010220105723.C85542@prism.flugsvamp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It would be fairly trivial to monitor a configuration file with kevent, :which would generate a notice whenever the file is changed/copied/renamed, :etc. I believe that John-Mark Gurney had patches somewhere to implement :exactly this for inetd. : :The problem is that under our current model, the administrators do not :expect writes to the file to take immediate effect, and this immediately :breaks POLA. So while it could be done, it may not be a good idea. At :the very least, I would argue that it should be hidden behind a flag option. :-- :Jonathan I don't even think it's that useful. Lets say you have a daemon (say, named) that requires several configuration files and you want to update all of them. Now how do you do it? I much rather like the idea of an editor-wrapper similar to vipw. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 10:41:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id 0E15637B401; Tue, 20 Feb 2001 10:41:16 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f1KGO8s04318; Tue, 20 Feb 2001 16:24:08 GMT (envelope-from nik) Date: Tue, 20 Feb 2001 16:24:08 +0000 From: Nik Clayton To: Will Andrews , Nik Clayton , Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010220162408.A4211@canyon.nothing-going-on.org> References: <3A8D9576.C9AC3045@integratus.com> <20010220150755.A3696@canyon.nothing-going-on.org> <20010220111759.A83214@ohm.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220111759.A83214@ohm.physics.purdue.edu>; from will@physics.purdue.edu on Tue, Feb 20, 2001 at 11:17:59AM -0500 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 11:17:59AM -0500, Will Andrews wrote: > On Tue, Feb 20, 2001 at 03:07:55PM +0000, Nik Clayton wrote: > > com1:dv=/dev/cuaa0:br#115200:pa=none: > > com2:dv=/dev/cuaa1:br#115200:pa=none: > > com3:dv=/dev/cuaa2:br#115200:pa=none: > > com4:dv=/dev/cuaa3:br#115200:pa=none: > > Yes. Not everything supports 115200bps communication. I'm happy to drop it to something else; 9600? I don't really care. But 'com1' is easier to type than 'cuaa0', without having to remember whether it's one 'u' and two 'a's, or two 'u's and one 'a'. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 11:17:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id 3099537B4EC; Tue, 20 Feb 2001 11:17:14 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.9.3/8.9.3) id OAA90586; Tue, 20 Feb 2001 14:17:12 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Tue, 20 Feb 2001 14:17:12 -0500 From: Will Andrews To: Nik Clayton Cc: Will Andrews , Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@freebsd.org Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010220141711.B83214@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , Nik Clayton , Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@freebsd.org References: <3A8D9576.C9AC3045@integratus.com> <20010220150755.A3696@canyon.nothing-going-on.org> <20010220111759.A83214@ohm.physics.purdue.edu> <20010220162408.A4211@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="kdyvsFMDMDKuFgXB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220162408.A4211@canyon.nothing-going-on.org>; from nik@freebsd.org on Tue, Feb 20, 2001 at 04:24:08PM +0000 X-Operating-System: FreeBSD 4.1-RELEASE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --kdyvsFMDMDKuFgXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2001 at 04:24:08PM +0000, Nik Clayton wrote: > I'm happy to drop it to something else; 9600? I don't really care. > But 'com1' is easier to type than 'cuaa0', without having to remember > whether it's one 'u' and two 'a's, or two 'u's and one 'a'. 9600 is good. --=20 wca --kdyvsFMDMDKuFgXB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6ksK3F47idPgWcsURAgp8AKCJ1TKwNa26+kK6jAWKdozMpbQ9AgCgkoWs gWl8k9rDl45/zAl3owSfMnc= =RfK4 -----END PGP SIGNATURE----- --kdyvsFMDMDKuFgXB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 12:15:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 76B6737B401 for ; Tue, 20 Feb 2001 12:15:36 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA77474; Tue, 20 Feb 2001 12:15:24 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200102202015.MAA77474@gndrsh.dnsmgr.net> Subject: Re: DJBDNS vs. BIND In-Reply-To: <3A92129E.7CD722F4@softweyr.com> from Wes Peters at "Feb 19, 2001 11:45:50 pm" To: wes@softweyr.com (Wes Peters) Date: Tue, 20 Feb 2001 12:15:24 -0800 (PST) Cc: cedric@wireless-networks.com (Cedric Berger), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Cedric Berger wrote: > > > > > Configuration data > > > on VMS was mostly stored in the form of "logical names", which are sort > > > of like persistent environment variables with different namespaces (per > > > system, per group, and per user). > > > > Well, the windows registry also provide such kind of centralized, > > persistent environment variables, with different namespaces > > (per system, per user)? > > > > At least, let's say that Windows way of storing configuration looks > > closer then VMS than UNIX. > > OK, except VMS didn't store them in some half-baked database file, and > didn't regularly scramble all of it. ;^) You never had to deal with a scrambled sysuaf.dat, rightlist.dat, netproxy.dat or a million other ``registry like'' .dat files on VMS? Your fortunate! (Yea, VMS was 10^6 times better about not doing this, but it still did it, and one could usually easily recover by deleting the highest version of the file (thank god for versions).) > The logicals on VMS were stored only in memory, and were created during > or after system boot by DSL procedures, the equivalent of shell scripts. ^^^ DCL > This is actually much more like UNIX than the Windows Registry. Take a look at ``DIR sys$system:*.dat'' some time and tell me that again... LNM is only one part of the picture... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 12:47:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 615FF37B491 for ; Tue, 20 Feb 2001 12:47:16 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f1KKlBC00848 for ; Tue, 20 Feb 2001 12:47:11 -0800 From: "Jonathan Graehl" To: Subject: modifying config files for a running daemon Date: Tue, 20 Feb 2001 12:48:19 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <20010220105723.C85542@prism.flugsvamp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there any way to be sure of receiving a change notification only after the writer has closed the file? I suppose that such a notification would not obviate flock(2)ing between editors (a quick glance at contrib/nvi shows that vi uses flock) and daemons (although, e.g. inetd simply opens the file without locking) -JG > It would be fairly trivial to monitor a configuration file with kevent, > which would generate a notice whenever the file is changed/copied/renamed, > etc. I believe that John-Mark Gurney had patches somewhere to implement > exactly this for inetd. > > The problem is that under our current model, the administrators do not > expect writes to the file to take immediate effect, and this immediately > breaks POLA. So while it could be done, it may not be a good idea. At > the very least, I would argue that it should be hidden behind a flag option. > -- > Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 12:59:11 2001 Delivered-To: freebsd-arch@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 D75BC37B4EC for ; Tue, 20 Feb 2001 12:59:08 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1KKwhg54340; Tue, 20 Feb 2001 14:58:43 -0600 (CST) (envelope-from jlemon) Date: Tue, 20 Feb 2001 14:58:43 -0600 From: Jonathan Lemon To: Jonathan Graehl Cc: freebsd-arch@FreeBSD.ORG Subject: Re: modifying config files for a running daemon Message-ID: <20010220145843.D85542@prism.flugsvamp.com> References: <20010220105723.C85542@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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 20, 2001 at 12:48:19PM -0800, Jonathan Graehl wrote: > Is there any way to be sure of receiving a change notification only after the > writer has closed the file? No, I don't think so. But even if that was the case, it doesn't eliminate the race condition where another process can open the file after the notification was sent. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 12:59:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 70E6937B401 for ; Tue, 20 Feb 2001 12:59:55 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1KKxhq64452; Tue, 20 Feb 2001 13:59:44 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102202059.f1KKxhq64452@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: Matt Dillon Cc: arch@freebsd.org Subject: Re: Summary of List of things to move from main tree to ports In-reply-to: Your message of "Fri, 16 Feb 2001 23:22:17 PST." <200102170722.f1H7MHm20405@earth.backplane.com> Date: Tue, 20 Feb 2001 13:59:43 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matt" == Matt Dillon writes: Matt> Robert Watson suggests, and others agree that the best Matt> way to handle UUCP is to change the NO_UUCP make.conf option Matt> into a BUILD_UUCP make.conf option. I would interject that, Matt> in addition to that, we should not create the uucp directory Matt> hierarchy unless uucp is selected in make.conf (i.e. not Matt> create /var/spool/uucppublic, a directory which defaults to Matt> modes 777, by default). Even if you do install UUCP, there's no requirement for this directory to exist. Matt> Robert Watson also makes the point Matt> about the suid/sgid nature of many uucp binaries, and I and Matt> others will attest to the fact that UUCP is simply not Matt> maintained anymore. That is a dangerous combination to have Matt> installed in the system by default. So if a maintainer is found there is no longer a reason to remove UUCP from the base, yes? Matt> Despite Terry's waxing poetic about Matt> UUCP's dialup capabilities, every soul I know (except maybe Matt> Terry) who has ever used UUCP in the past no longer does Matt> (and I should know: I wrote AmigaUUCP!). I use it. Constantly. Over dialup and TCP. As do a number of sites I'm affiliated with. Matt> However, if those Matt> people are going to make a big deal about it, I suppose we Matt> can take the intermediate step of having a BUILD_UUCP Matt> make.conf (opt-in) option for the next few years. Hey, WE aren't making the big deal. YOU are the one talking about yanking out a perfectly functional piece of the OS. The justification for removing UUCP is stated to be: It's not maintained, and it's full of security holes. I'll agree with the first point. I'm not convinced of the second (nor am I ruling it out). Let me address the first point by stepping forward and volunteering to be maintainer of the UUCP code. I've been using/debugging/enhancing UUCP since 1985, so it's not a big deal. Presuming that happens, I have ideas for addressing the second point. E.g.: Much of the set[ug]uid-ness in UUCP can be eliminated by using IPC mechanisms to communicate between the user-land commands and the backend spooling system. Well? --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 13:10:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id B51A337B401 for ; Tue, 20 Feb 2001 13:10:35 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id OAA40810; Tue, 20 Feb 2001 14:10:06 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdqbhDaa; Tue Feb 20 14:10:02 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA27450; Tue, 20 Feb 2001 14:10:27 -0700 (MST) From: Terry Lambert Message-Id: <200102202110.OAA27450@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: rjesup@wgate.com Date: Tue, 20 Feb 2001 21:10:27 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: from "Randell Jesup" at Feb 20, 2001 11:31: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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There's still a synchronization problem, even if the hostname > is in shared memory, even if the write is atomic (a reader may be in the > middle of reading the string). The easiest way to deal with this is to put the access behind an API, to guarantee atomicity. But there is a better way. > Fetching the data out of a kernel service on each access would be > (potentially) a pretty major hit, performance-wise. Some form of > registration of interest in the data would be better. Either something > like the Amiga (get a signal/message/callback/whatever when it changes, > then request the new information), or something that passes the > notification along with the new data. The approach I was thinking of would be to map the pages with the data in them read/write in kernel space, and read-only in all user space programs. The updates could be atomic by way of page replacement, which avoids the "middle of the string" problem. Pages are replaced prior to swap in on the next quantum (late binding). Writes would be by way of a system call API. The obvious one to use is "sysctl". Normal use would mean that this was zero overhead, which is better than getting the data from a file, anyway. Getting back to the system, group, and user logical naming, you could actually push the environment into the kernel; this would break direct references to "environ" (very old code), which is no loss, but it would potentially complicate the heck out of execve(), unless it were done right (stupid POSIX...). 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 13:12:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 7917437B401 for ; Tue, 20 Feb 2001 13:12:32 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152CZ9H7; Tue, 20 Feb 2001 16:12:27 -0500 Reply-To: Randell Jesup To: "Jonathan Graehl" Cc: Subject: Re: modifying config files for a running daemon References: From: Randell Jesup Date: 20 Feb 2001 16:13:03 -0500 In-Reply-To: "Jonathan Graehl"'s message of "Tue, 20 Feb 2001 12:48:19 -0800" Message-ID: 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jonathan Graehl" writes: >Is there any way to be sure of receiving a change notification only after the >writer has closed the file? At the moment, I don't think so, since there's no change notification. Certainly it wouldn't be tough to create a protocol/API that provided that functionality, at least if you can guarantee that the writer uses the protocol, or by use of a special pseudo-fs, etc. Since a change-notification protocol/API would need to be defined anyways, there wouldn't be a problem including this. I believe that the support for file notification in the Amiga ramdisk notified on close of a modified file (I've lost too many neurons to be sure). Providing it on an arbitrary FS _without_ requiring the writer to use the defined protocol would be quite a hairy change to make, of course. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 13:16:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 998A537B4EC for ; Tue, 20 Feb 2001 13:16:20 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA15280; Tue, 20 Feb 2001 14:13:14 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAMNa4YD; Tue Feb 20 14:13:05 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA27627; Tue, 20 Feb 2001 14:16:09 -0700 (MST) From: Terry Lambert Message-Id: <200102202116.OAA27627@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Tue, 20 Feb 2001 21:16:09 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20010220105723.C85542@prism.flugsvamp.com> from "Jonathan Lemon" at Feb 20, 2001 10:57:23 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It would be fairly trivial to monitor a configuration file with kevent, > which would generate a notice whenever the file is changed/copied/renamed, > etc. I believe that John-Mark Gurney had patches somewhere to implement > exactly this for inetd. > > The problem is that under our current model, the administrators do not > expect writes to the file to take immediate effect, and this immediately > breaks POLA. So while it could be done, it may not be a good idea. At > the very least, I would argue that it should be hidden behind a flag option. This is what makes something with an API a better bet, since you can define it to be a semantic of the API. That prevents a POLA violation. I like that people are willing to at least discuss using a new API that isn't implemented everywhere; many of the system calls we have today started out that way, too, and it was use, which proved their utility, which propelled them to the level of a standard. Lets not hamstring ourselves over having to hide such a fundamental improvement behind a flag, before we even know the shapes it might take. We'll have the rest of time to be self limiting, after we figure out what it should look like. 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 13:18:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id DDEB837B401 for ; Tue, 20 Feb 2001 13:18:47 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152CZ9Z8; Tue, 20 Feb 2001 16:18:34 -0500 Reply-To: Randell Jesup To: Jonathan Lemon Cc: Jonathan Graehl , freebsd-arch@FreeBSD.ORG Subject: Re: modifying config files for a running daemon References: <20010220105723.C85542@prism.flugsvamp.com> <20010220145843.D85542@prism.flugsvamp.com> From: Randell Jesup Date: 20 Feb 2001 16:19:10 -0500 In-Reply-To: Jonathan Lemon's message of "Tue, 20 Feb 2001 14:58:43 -0600" Message-ID: 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon writes: >On Tue, Feb 20, 2001 at 12:48:19PM -0800, Jonathan Graehl wrote: >> Is there any way to be sure of receiving a change notification only >> after the writer has closed the file? > >No, I don't think so. But even if that was the case, it doesn't eliminate >the race condition where another process can open the file after the >notification was sent. Assuming the writers are using flock() (exclusive), you have the reader use flock() (perhaps/probably in shared mode). As the original author said, this doesn't obviate the need to deal with locks. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 13:26:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 273EC37B401 for ; Tue, 20 Feb 2001 13:26:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id OAA15394; Tue, 20 Feb 2001 14:20:42 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAV3aaRD; Tue Feb 20 14:20:08 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA27852; Tue, 20 Feb 2001 14:25:31 -0700 (MST) From: Terry Lambert Message-Id: <200102202125.OAA27852@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 20 Feb 2001 21:25:31 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <200102201804.f1KI4HG45260@earth.backplane.com> from "Matt Dillon" at Feb 20, 2001 10:04:17 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... caching considered harmful ... ] > I don't even think it's that useful. Lets say you have a daemon (say, > named) that requires several configuration files and you want to > update all of them. Now how do you do it? DNSUPDAT, over socket 53. > I much rather like the idea of an editor-wrapper similar to vipw. That's a useful approach for externalized security data, where you can have an arbitrary amount of it lying around, but it's much less useful for, as an example, the hostname. Even for security data, really, the modifications should be hidden behind a PAM interface, with a program on the front end to do the work. If you still have a vipw after that, it's a program which externalizes the data, edits it, and then reinternalizes it (vipw today doesn't externalize the database contents, it operates on a flat file, which is then processed to create the database). For very large password lists, you need a programatic method, and that method has to be able to operate incrementally. This practically screams to discard the flat files. Actually, the hostname is particularly interesting, since you will have to partition the data so that you can have multiple instances; this is real obvious if you think in the context of how such daemons would need to be able to operate in "jails" (e.g. multiple copies of sendmail or other dameons). 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 14:19:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id CCBD337B684 for ; Tue, 20 Feb 2001 14:19:14 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id PAA79236; Tue, 20 Feb 2001 15:18:47 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdMN7pMa; Tue Feb 20 15:18:39 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA28977; Tue, 20 Feb 2001 15:19:04 -0700 (MST) From: Terry Lambert Message-Id: <200102202219.PAA28977@usr05.primenet.com> Subject: Re: modifying config files for a running daemon To: rjesup@wgate.com Date: Tue, 20 Feb 2001 22:18:59 +0000 (GMT) Cc: jonathan@graehl.org (Jonathan Graehl), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Randell Jesup" at Feb 20, 2001 04:13:03 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At the moment, I don't think so, since there's no change > notification. Certainly it wouldn't be tough to create a protocol/API that > provided that functionality, at least if you can guarantee that the writer > uses the protocol, or by use of a special pseudo-fs, etc. Since a > change-notification protocol/API would need to be defined anyways, there > wouldn't be a problem including this. I believe that the support for file > notification in the Amiga ramdisk notified on close of a modified file > (I've lost too many neurons to be sure). > > Providing it on an arbitrary FS _without_ requiring the writer to > use the defined protocol would be quite a hairy change to make, of course. Actually, it's pretty trivial; it's one area where a stacking layer wouldn't need it's own vnodes in order to stack. You could do it by building a pseudo-vector instance for each mount when you were creating the VFS instance. The pseudo-vector would catch the event, and then call the real vector. You couldn't just tag the system calls, since write faults as a result of mmap() don't go through the system call path. Adding the code to vfs_init() would be pretty trivial. While you were there, sorting the decriptos in the vector list would let them be referenced directly by offset, and remove a level of indirection for each layer transition, making the overall use of the VFS framework less expensive. On a general note... This is one of the (many) obvious places where the object contents are not rearranged by a stacking layer, so the layer implementing it doesn't need a vnode/vmobject_t association. If we could rip that assumption out of the VFS, almost all of our cache coherency issues would magically disappear. The only places they wouldn't would be in translation layers (compression, encryption, name space conversion, character set conversion, etc.), where the view in user space of the object isn't the same as the view in the backing store. This is really a tiny fraction of the problem space VFS' are capable of mapping. 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-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 17: 2:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 1C98537B401 for ; Tue, 20 Feb 2001 17:02:08 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1L12Hk25567; Wed, 21 Feb 2001 01:02:18 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f1L13Ed21835; Wed, 21 Feb 2001 01:03:14 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Brian Somers , arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. In-Reply-To: Message from Warner Losh of "Thu, 15 Feb 2001 20:58:53 MST." <200102160358.f1G3wrW56778@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 01:03:14 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Right, but binaries from before your first commit (1 above) are > : potentially dead in the water - (yep, you already know this, but this > : is my concern -- see below). > > I don't understand this, so I'll draw a timeline and see if you can > tell me what you are talking about: > > libc.so.3 ----- libc.so.4 ---- libc.so.5 ---- Feb 10 --- Today --- tomorrow > 1 2 3 4 5 6 > > The only area that I know that binaries programs will be busted is the > 4 - 5 period. The rest should be good to go with this, assuming that > their libc can be updated with the latest cool bits. Consider this: $ cd /usr/local/lib $ objdump -x libmm.so.11 | fgrep libc.so NEEDED libc.so.4 $ nm libmm.so.11 | fgrep -w __sF U __sF $ objdump -x libjpeg.so.9 | fgrep libc.so $ nm libjpeg.so.9 | fgrep -w __sF U __sF $ objdump -x libmd5.so.1 | fgrep libc.so $ nm libmd5.so.1 | fgrep -w __sF So we've got three types of library. libmm is the nice type. It depends on libc and uses sF. This is the way things should be. libmd5 doesn't matter because it doesn't (seem to) use anything to do with stdio. The problem is the libjpeg case. It has no dependency on libc (this is what I think is a linker bug - the linker should put dependencies in there implicitly) but uses sF. This is the ``evil'' library. We need to bump it's version number so that we can have a new (default) one that knows about whatever magic will avoid knowledge of the sizeof FILE, while not breaking old binaries (that know about the old version). I guess (??!?) that libraries such as libmm.so.11 (which depend on libc.so.4) will refuse to take part in linking a dynamic binary against libc.so.5... ie: cc -o blah blah.o -lmm when libc.so -> libc.so.5, libmm.so -> libmm.so.11 and libmm.so.11 has a dependency on libc.so.4. Whether it does or not, we probably need a new libmm version number too... The end result still seems to mean that we need new version numbers on all libraries if sizeof FILE changes :-/ > Warner -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 20:54:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 71EF337B491 for ; Tue, 20 Feb 2001 20:54:25 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0477666F2E; Tue, 20 Feb 2001 20:54:24 -0800 (PST) Date: Tue, 20 Feb 2001 20:54:24 -0800 From: Kris Kennaway To: Steve Kargl Cc: Bruce Evans , arch@FreeBSD.org Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010220205424.B44290@mollari.cthul.hu> References: <200102210428.f1L4Se482578@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102210428.f1L4Se482578@troutmask.apl.washington.edu>; from sgk@troutmask.apl.washington.edu on Tue, Feb 20, 2001 at 08:28:40PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2001 at 08:28:40PM -0800, Steve Kargl wrote: > Bruce Evans wrote: > > On Tue, 20 Feb 2001, Warner Losh wrote: > >=20 > >> In message <200102200837.f1K8bpj89576@freefall.freebsd.org> Kris Kenna= way writes: > >> : We now set up the reasonable default for i386 and alpha here -- gi= ven this > >> : it probably makes sense to remove the corresponding code from make= (1). > >>=20 > >> Probably not. We really do not want to pollute sys.mk with any more > >> variables than we absolutely have to. It is included for all > >> Makefiles on the system, not just the ones to build the system. > >> Adding things there can cause problems elsewhere. > >=20 > > But polluting make(1) is almost equivalent to polluting sys.mk. The > > pollution is just easier to implement and harder to remove in make(1). > >=20 > > I have changed my mind a bit about this. MACHINE_CPU is not (yet?) nea= rly > > as fundamental as the other MACHINE_* variables. It is currently just > > a build option for libcrypto, so it could be handled like other build > > options. > >=20 >=20 > libgmp (if updated to the neest release) can use a MACHINE_CPUi > variable. Although I should note that Kris wants (has expressed > a desire) to remove libgmp from the base tree. There's also a dozen or more ports which will be making use of this. Kris --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6k0oAWry0BWjoQKURAul3AJ9tVFgzbvant4OC91jKLTs4D8+KUACcCga9 sCYeIB/H0JX1ODs2c/9NfgA= =Yg2J -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 21: 4:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5073E37B491 for ; Tue, 20 Feb 2001 21:04:27 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA02594; Wed, 21 Feb 2001 16:04:15 +1100 Date: Wed, 21 Feb 2001 16:03:42 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] In-Reply-To: <20010220011548.A34873@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Feb 2001, Kris Kennaway wrote: > What does this list think about the merits of this idea? It won't help much with portability. getprogname() and setprogname() are currently even more unportable than __progname, and their names don't indicated that they should not be used in applications. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 21:17: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6725937B684 for ; Tue, 20 Feb 2001 21:17:02 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1L5H0h60720; Tue, 20 Feb 2001 22:17:01 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1L5ENs04902; Tue, 20 Feb 2001 22:14:23 -0700 (MST) Message-Id: <200102210514.f1L5ENs04902@billy-club.village.org> To: Brian Somers Subject: Re: The whole libc thing. Cc: arch@freebsd.org In-reply-to: Your message of "Wed, 21 Feb 2001 01:03:14 GMT." <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> References: <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> Date: Tue, 20 Feb 2001 22:14:23 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> Brian Somers writes: : The problem is the libjpeg case. It has no dependency on libc : (this is what I think is a linker bug - the linker should put : dependencies in there implicitly) but uses sF. This is the ``evil'' : library. Right. This is case 3 that I talked about in an earlier post. : We need to bump it's version number so that we can have a new : (default) one that knows about whatever magic will avoid knowledge : of the sizeof FILE, while not breaking old binaries (that know about : the old version). No. That's not right. We can just recompile it with the new libc. With the backwards compatibility shims I put into libc, this will just work. : I guess (??!?) that libraries such as libmm.so.11 (which depend on : libc.so.4) will refuse to take part in linking a dynamic binary : against libc.so.5... ie: I don't think so. I've seen the NEEDED stuff routinely ignored. : The end result still seems to mean that we need new version numbers : on all libraries if sizeof FILE changes :-/ Or a revisionist history. If we want each and every library to always work, then we do need to bump every single shared library major version number. However, we the shims I put in place, we can just recompile things and the evil dependency on sizeof FILE will disappear. I think we are stuck with __sF through the end of life of libc.so.5, however, so the point is somewhat moot. By that time, however, all new libraries will be using __std*, and there will be working libc.so.3 and libc.so.4 by then that will bridge the gap. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 21:27:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 47D0A37B491 for ; Tue, 20 Feb 2001 21:27:37 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DAA7366F2E; Tue, 20 Feb 2001 21:27:36 -0800 (PST) Date: Tue, 20 Feb 2001 21:27:36 -0800 From: Kris Kennaway To: Warner Losh Cc: Bruce Evans , arch@FreeBSD.org Subject: Re: cvs commit: src/share/mk sys.mk' Message-ID: <20010220212736.A45166@mollari.cthul.hu> References: <200102210521.f1L5Lds04947@billy-club.village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102210521.f1L5Lds04947@billy-club.village.org>; from imp@village.org on Tue, Feb 20, 2001 at 10:21:38PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2001 at 10:21:38PM -0700, Warner Losh wrote: > In message Bru= ce Evans writes: > : I have changed my mind a bit about this. MACHINE_CPU is not (yet?) nea= rly > : as fundamental as the other MACHINE_* variables. It is currently just > : a build option for libcrypto, so it could be handled like other build > : options. >=20 > So are you saying we should just toss a MACHINE_CPU ?=3D ${MACHINE_ARCH} > in /etc/defaults/make.conf and be done with it. If we did this, with > a sys.mk transition period, we'd solve the long term problem of too > many things in sys.mk while still allowing for this to move forward. Well, it's not ?=3D ${MACHINE_ARCH} because on the alpha it should be (at least) 'ev4'. You'd need to stick the current logic from sys.mk in /etc/make.conf or some other universally-used makefile -- personally I don't care where it ends up as long as it works. =2Eif ${MACHINE_ARCH} =3D=3D "i386" MACHINE_CPU ?=3D i386 =2Eelif ${MACHINE_ARCH} =3D=3D "alpha" MACHINE_CPU ?=3D ev4 =2Eendif Kris --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6k1HIWry0BWjoQKURAuxGAJ9LPynlqT0zQn1TUcGImkk99QxlzQCfUyFT Y37t3L7h06yXdnDJ7ndUtCI= =B26M -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 20 21:43:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5B1E637B491 for ; Tue, 20 Feb 2001 21:43:41 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1L5hYh60863; Tue, 20 Feb 2001 22:43:37 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1L5evs05154; Tue, 20 Feb 2001 22:40:57 -0700 (MST) Message-Id: <200102210540.f1L5evs05154@billy-club.village.org> To: Kris Kennaway Subject: Re: cvs commit: src/share/mk sys.mk' Cc: Bruce Evans , arch@FreeBSD.org In-reply-to: Your message of "Tue, 20 Feb 2001 21:27:36 PST." <20010220212736.A45166@mollari.cthul.hu> References: <20010220212736.A45166@mollari.cthul.hu> <200102210521.f1L5Lds04947@billy-club.village.org> Date: Tue, 20 Feb 2001 22:40:57 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010220212736.A45166@mollari.cthul.hu> Kris Kennaway writes: : personally I don't care where it ends up as long as it works. I think that /etc/defaults/make.conf woudl work, but you have the bootstrapping problem. I'd put it in both sys.mk and defaults/make.conf and then remove it from sys.mk after the next major release. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 2:29:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from muncher.math.uic.edu (koobera.math.uic.edu [131.193.178.181]) by hub.freebsd.org (Postfix) with SMTP id E1DF337B491 for ; Wed, 21 Feb 2001 02:29:41 -0800 (PST) (envelope-from djb-dsn-982751402.3475@cr.yp.to) Received: (qmail 1863 invoked by uid 1001); 21 Feb 2001 10:30:03 -0000 Date: 21 Feb 2001 10:30:02 -0000 Message-ID: <20010221103002.3475.qmail@cr.yp.to> From: "D. J. Bernstein" To: arch@freebsd.org Cc: djb@cr.yp.to Subject: Re: DJBDNS vs. BIND Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 1. Ever heard of citysearch.com? All their DNS records are published by djbdns. Thousands more sites have switched to djbdns. One site is using djbdns to publish records for hundreds of thousands of *.com's. But Terry claims that djbdns is suitable only for ``trivial uses.'' Wow. See http://cr.yp.to/djbdns.html and investigate the facts for yourself. I bet you'll be happy with djbdns. If you have questions, send them to my dns mailing list. 2. It takes just a few seconds for tinydns-data to rebuild a typical 10000-zone database and for rsync to push new data to secondaries. In contrast, for the same number of zones, BIND waits an average of about 7 _minutes_ before it sends NOTIFY. Terry is wrong when he claims that there's no latency with BIND; there is, in fact, massive latency. 3. The necessary use of rsync is a straightforward one-line command in /service/tinydns/root/Makefile, as shown in the djbdns documentation. Terry is wrong when he claims that ``synchronization is left as an exercise for the student.'' 4. A new tinydns database atomically replaces the previous database. The server switches to the new database for the next query. Terry is wrong when he claims that tinydns ``must be restarted for the updates to take effect.'' He is wrong when he claims that frequent updates would result in the server being ``largely unavailable.'' (Terry is also wrong when he implies that restarts are slow. Starting or restarting tinydns takes a tiny fraction of a second. But this is a side issue; there is _no_ outage when a database is updated.) 5. I have gone to great lengths to support DNS administration protocols. For example, I designed the tinydns data format to be very easily editable by external programs. Terry is wrong when he claims that I am ``opposed to protocol level modification of DNS server contents.'' However, I do oppose Microsoft-style ``embrace and extend'' tactics. The big problem with the BIND modification protocol is that the protocol was (deliberately!) wedged into port 53. This is extremely inconvenient for modular servers. 6. I designed the djbdns server architecture so that one could easily write servers using different types of databases. Look at tinydns and rbldns and walldns (and pickdns, though tinydns now has the same features) in the package. Or look at Bruce Guenter's sqldjbdns. Terry is wrong when he claims that I am ``strongly opposed to offering alternate back ends.'' There is no truth to Terry's insinuations that I rejected Terry's SQL ideas. There is also no truth to the similar insinuations from Jack Rusher and Wes Peters. In fact, as far as I can tell, these people have _never_ sent any email to the dns mailing list. 6. Before tinydns (or dnscache) sees any untrusted data, it chroots and drops privileges. Inserting an exec at this point would have no security benefits and would turn installation into a chroot-BIND-style nightmare. Terry is being silly when he says that ``you have to wonder'' about the lack of an exec. 7. djbdns is highly modular. Almost all of the program-level modules, and many of the internal C functions, are thoroughly documented on my web pages; Matt is wrong when he says ``the code is uncommented.'' For further discussion of code readability, see my bugtraq postings on the Dijkstra phenomenon. ---Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 2:40:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 69C2E37B4EC for ; Wed, 21 Feb 2001 02:40:39 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E082666F2E; Wed, 21 Feb 2001 02:40:38 -0800 (PST) Date: Wed, 21 Feb 2001 02:40:38 -0800 From: Kris Kennaway To: "D. J. Bernstein" Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND Message-ID: <20010221024038.A50175@mollari.cthul.hu> References: <20010221103002.3475.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221103002.3475.qmail@cr.yp.to>; from djb@cr.yp.to on Wed, Feb 21, 2001 at 10:30:02AM -0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please, if anyone is going to follow up to this, do it on -chat where it belongs. Kris --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6k5smWry0BWjoQKURAuYhAKCZcDYZR9Dv29C6T9W8Do+g52N1HwCgheRJ 7yhiqGDajKIRGgI3sdl+m/8= =vEv+ -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 5:22:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 044A937B491 for ; Wed, 21 Feb 2001 05:22:27 -0800 (PST) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA38196; Wed, 21 Feb 2001 14:22:25 +0100 (CET) (envelope-from assar) To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] References: <20010220011548.A34873@mollari.cthul.hu> From: Assar Westerlund Date: 21 Feb 2001 14:22:24 +0100 In-Reply-To: Kris Kennaway's message of "Tue, 20 Feb 2001 01:15:48 -0800" Message-ID: <5l66i4rx0v.fsf@assaris.sics.se> Lines: 44 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway writes: > What does this list think about the merits of this idea? I think it's a good idea, but then I'm partially responsible for the [sg]et_progname functions in libroken (used by krb4, heimdal and others) that influenced this. :-) /assar > ----- Forwarded message from "Chris G. Demetriou" ----- > > Delivered-To: kkenn@localhost.obsecurity.org > Delivered-To: kris@freebsd.org > Delivered-To: source-changes@netbsd.org > From: "Chris G. Demetriou" > Subject: CVS commit: basesrc > To: source-changes@netbsd.org > Reply-To: cgd@netbsd.org > Date: Tue, 20 Feb 2001 00:13:23 +0200 (EET) > Precedence: list > X-UIDL: 765b2d66d1c210d4309e91f0561210ff > > > Module Name: basesrc > Committed By: cgd > Date: Mon Feb 19 22:13:23 UTC 2001 > > Added Files: > basesrc/lib/libc/gen: getprogname.3 getprogname.c setprogname.c > > Log Message: > add getprogname() and setprogname(). These allow uses of __progname to > be wrapped in some sane fashion, for portability. > > > To generate a diff of this commit: > cvs rdiff -r0 -r1.1 basesrc/lib/libc/gen/getprogname.3 \ > basesrc/lib/libc/gen/getprogname.c basesrc/lib/libc/gen/setprogname.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > > > ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 5:25: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 6CAF437B699 for ; Wed, 21 Feb 2001 05:25:04 -0800 (PST) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA38202; Wed, 21 Feb 2001 14:24:57 +0100 (CET) (envelope-from assar) To: Bruce Evans Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] References: From: Assar Westerlund Date: 21 Feb 2001 14:24:57 +0100 In-Reply-To: Bruce Evans's message of "Wed, 21 Feb 2001 16:03:42 +1100 (EST)" Message-ID: <5l1yssrwwm.fsf@assaris.sics.se> Lines: 13 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans writes: > It won't help much with portability. getprogname() and setprogname() > are currently even more unportable than __progname, and their names > don't indicated that they should not be used in applications. But they're supposed to be used in applications. They are helpful when porting BSD programs that use {err,warn}{,x} (thus relying on the presence of a __progname). When porting these to non-BSD systems, you only need to add the trivial implementation of {s,g}etprogname. Which, I would like to add, was the original rationale for having these functions. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 8:49:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 9887237B65D; Wed, 21 Feb 2001 08:49:26 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f1LG9D905894; Wed, 21 Feb 2001 16:09:13 GMT (envelope-from nik) Date: Wed, 21 Feb 2001 16:09:12 +0000 From: Nik Clayton To: Will Andrews , Nik Clayton , Jack Rusher , Robert Watson , Lyndon Nerenberg , arch@freebsd.org Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010221160912.A5780@canyon.nothing-going-on.org> References: <3A8D9576.C9AC3045@integratus.com> <20010220150755.A3696@canyon.nothing-going-on.org> <20010220111759.A83214@ohm.physics.purdue.edu> <20010220162408.A4211@canyon.nothing-going-on.org> <20010220141711.B83214@ohm.physics.purdue.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220141711.B83214@ohm.physics.purdue.edu>; from will@physics.purdue.edu on Tue, Feb 20, 2001 at 02:17:12PM -0500 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 20, 2001 at 02:17:12PM -0500, Will Andrews wrote: > On Tue, Feb 20, 2001 at 04:24:08PM +0000, Nik Clayton wrote: > > I'm happy to drop it to something else; 9600? I don't really care. > > But 'com1' is easier to type than 'cuaa0', without having to remember > > whether it's one 'u' and two 'a's, or two 'u's and one 'a'. > > 9600 is good. Will do. Incidentally, the manual page says the br attribute is for a baud rate. I'm pretty certain that, in the technical sense of the word, it's actually talking about the bits-per-second rate. How do people feel about the attached patch? N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=d Index: remote.5 =================================================================== RCS file: /home/ncvs/src/share/man/man5/remote.5,v retrieving revision 1.6 diff -u -r1.6 remote.5 --- remote.5 2000/11/20 18:41:29 1.6 +++ remote.5 2001/02/21 16:08:39 @@ -68,7 +68,7 @@ as follows. When .Nm tip is invoked with only a phone number, it looks for an entry -of the form ``tip300'', where 300 is the baud rate with +of the form ``tip300'', where 300 is the bit rate with which the connection is to be made. When the .Nm cu interface is used, entries of the form ``cu300'' are used. @@ -86,10 +86,10 @@ Auto call unit type. .It Cm \&br (num) -The baud rate used in establishing +The bits-per-second rate used in establishing a connection to the remote host. This is a decimal number. -The default baud rate is 300 baud. +The default rate is 300 bits-per-second. .It Cm \&cm (str) An initial connection message to be sent --Kj7319i9nmIyA2yE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 11:49:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id DF64E37B491 for ; Wed, 21 Feb 2001 11:49:37 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C5JGR; Wed, 21 Feb 2001 14:49:42 -0500 Reply-To: Randell Jesup To: Terry Lambert Cc: jonathan@graehl.org (Jonathan Graehl), freebsd-arch@FreeBSD.ORG Subject: Re: modifying config files for a running daemon References: <200102202219.PAA28977@usr05.primenet.com> From: Randell Jesup Date: 21 Feb 2001 14:50:23 -0500 In-Reply-To: Terry Lambert's message of "Tue, 20 Feb 2001 22:18:59 +0000 (GMT)" Message-ID: 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: >> Providing it on an arbitrary FS _without_ requiring the writer to >> use the defined protocol would be quite a hairy change to make, of course. > >Actually, it's pretty trivial; it's one area where a stacking >layer wouldn't need it's own vnodes in order to stack. > >You could do it by building a pseudo-vector instance for each >mount when you were creating the VFS instance. The pseudo-vector >would catch the event, and then call the real vector. Hmmm, I hadn't considered the VFS layer. Ignoring networked FS's (since NFS wouldn't support this directly, I assume, without extensions), this should work. >You couldn't just tag the system calls, since write faults as >a result of mmap() don't go through the system call path. Right. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 12:14:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 8E63C37B491 for ; Wed, 21 Feb 2001 12:14:35 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f1LKEQF07832 for ; Wed, 21 Feb 2001 12:14:26 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: Why are ICMP redirects observed by default? Date: Wed, 21 Feb 2001 12:15:45 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I thought ICMP redirects had fallen out of favor; is the security risk (an interloper being able to change routing tables) considered insignificant for leaf or edge machines? Do redirects actually help performance in the real world? Of course, there is nothing to complain about, since the behavior can be toggled; I am simply curious as to what the current feeling about them is (aside from the warm fuzzy feeling of RFC-compliance) # sysctl -a | grep redirect net.inet.ip.redirect: 1 net.inet.icmp.drop_redirect: 0 net.inet.icmp.log_redirect: 0 -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ phone: 858-642-7562 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 12:35:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 499F537B401 for ; Wed, 21 Feb 2001 12:35:18 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f1LKZBD58861; Wed, 21 Feb 2001 15:35:15 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200102212035.f1LKZBD58861@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Jonathan Graehl" Cc: "freebsd-Arch" X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Why are ICMP redirects observed by default? References: In-reply-to: Your message of "Wed, 21 Feb 2001 12:15:45 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 15:35:11 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I thought ICMP redirects had fallen out of favor; is the security risk (an > interloper being able to change routing tables) considered insignificant for > leaf or edge machines? Do redirects actually help performance in the real > world? Of course, there is nothing to complain about, since the behavior can be > toggled; I am simply curious as to what the current feeling about them is (aside > from the warm fuzzy feeling of RFC-compliance) If you have a subnetwork with a bunch of end-system (hosts), and more than one egress choice (e.g., multiple routers on the same LAN), then ICMP redirects can be very useful. If you don't have this situation, then running with a static default route, or running a simple router discovery protocol is adequate; you're not trying to choose between alternative, you're just trying to discover the *only* alternative. The alternative scenario is that the end-systems have to particpate in some routing infrastructure. That is, you run something like gated or routed and either actively participate or "wire-tap" the routing protocol to figure out what router to use for each destination when there are multiple alternatives to choose between. This can be a pain, since you've now coupled the administration of the routing infrastructure to behavior that end-systems see, which needlessly complicates administrating the overall system. So, you can simply use rdiscd to find a default route to a working router. If that happens to be the wrong choice for a particular destination, a redirect is generated for that destination to the end host. It uses that for a while, and then times it out. Note that you can still run VRRP or someother mechanism to find *any* working router; redirects are used to refine the per-destination choice. If you don't generate the redirect, then the default router had to forward the packet back across the same LAN to the egree router which should have been used in the first place. This wastes forwarding capacity on the first router and network bandwidth (though if it's a switched network, this is less of an issue.) You probably ought to filter out ICMP redirects coming from non-local sources. They clearly don't make any sense. But PLEASE, don't just nuke all ICMP messages; no sense in needlessly breaking path MTU discovery. Of course the assumption is that the routers on the subnetwork are aware of each other, and thus can know when to generate a redirect to an alterantive. If this isn't the case, well, then you're already in the land of "special" and none of this probably applies to you. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 12:38:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 72ACE37B401 for ; Wed, 21 Feb 2001 12:38:36 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 83A7366F2E; Wed, 21 Feb 2001 12:38:35 -0800 (PST) Date: Wed, 21 Feb 2001 12:38:35 -0800 From: Kris Kennaway To: mi@aldan.algebra.com Cc: arch@freebsd.org Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221123835.A59024@mollari.cthul.hu> References: <200102211827.f1LIRuv32516@misha.privatelabs.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102211827.f1LIRuv32516@misha.privatelabs.com>; from mi@aldan.algebra.com on Wed, Feb 21, 2001 at 01:27:54PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 21, 2001 at 01:27:54PM -0500, mi@aldan.algebra.com wrote: > BTW, may be -mcpu=${MACHINE_CPU} can be added to the default CFLAGS now? > And a comment, that changing -mcpu to -march will, probably, be even > better, but will prevent the binaries from being usable on earlier CPUs. Well, MACHINE_CPU is a list, not a word. And gcc doesn't support optimizations for all of the values we will be supporting (e.g. a lot of ports contain things like 3DNOW! asm code, etc). You could however imagine playing games with things like: .if ${MACHINE_CPU:Mi686} CFLAGS += -mpentiumpro .elif ${MACHINE_CPU:Mi586} CFLAGS += -mpentium ... .endif which may be worthwhile to do. The -march statement doesnt matter though, since some binaries built with MACHINE_CPU set will already be CPU-specific (e.g. if you specify i686 then openssl will use the i686 blowfish code) Kris P.S. Trying yet again to move this thread onto -arch where it belongs. --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lCdKWry0BWjoQKURAgdNAJ4oYRTIFiythJ2QUVgeFR4ObXQmlwCg5Wgy iVxKii+jHJeYEECCRtDWWZo= =8pXR -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 12:45:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 8509A37B491 for ; Wed, 21 Feb 2001 12:45:52 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2F30566F2E; Wed, 21 Feb 2001 12:45:52 -0800 (PST) Date: Wed, 21 Feb 2001 12:45:52 -0800 From: Kris Kennaway To: arch@FreeBSD.org Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221124552.A59188@mollari.cthul.hu> References: <200102211827.f1LIRuv32516@misha.privatelabs.com> <20010221114805.A96924@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221114805.A96924@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Feb 21, 2001 at 11:48:05AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2001 at 11:48:05AM -0800, David O'Brien wrote: > On Wed, Feb 21, 2001 at 01:27:54PM -0500, mi@aldan.algebra.com wrote: > > BTW, may be -mcpu=3D${MACHINE_CPU} can be added to the default CFLAGS n= ow? >=20 > I am nervous about this on the Alpha unless very well tested. We all > know that an ev4 system as the ev4 cannot handled ev56-only instructions. This applies to the i386 as well (i386 can't handle i586 instructions) > processor you specify. If you do not specify a processor type, GCC > will default to the processor on which the compiler was built. This would be taken care of by the default settings of MACHINE_CPU=3Dev4, which would (if we went down this path, see my previous mail) add an explicit -mcpu=3Dev4 to the release (and all other) builds. If you know your builds are only ever going to be used on an ev5 or whatever, you can set MACHINE_CPU=3Dev5 ev4 in /etc/make.conf and the hypothetical makefile logic would use -mcpu=3Dev5 instead. Kris P.S. Moving to arch for a 4th or 5th time. cvs-all isn't a discussion list, remember? :) --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lCj/Wry0BWjoQKURAk/rAJ0TZePQgzMvycuurT3HXj4scmqvTQCeKtbS rAt0T3PJdj2rfxHi+fY+E2c= =pGo+ -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 14:30:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 1569A37B4EC for ; Wed, 21 Feb 2001 14:30:48 -0800 (PST) (envelope-from daemon@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14VhmY-0008Qg-01; Wed, 21 Feb 2001 23:30:46 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.2/8.11.1) id f1LMDV512518 for freebsd-arch@freebsd.org; Wed, 21 Feb 2001 23:13:31 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: List of things to move from main tree to ports Date: Wed, 21 Feb 2001 22:13:31 +0000 (UTC) Message-ID: <971eib$akf$1@kemoauc.mips.inka.de> References: <20010220162408.A4211@canyon.nothing-going-on.org> <20010220141711.B83214@ohm.physics.purdue.edu> <20010221160912.A5780@canyon.nothing-going-on.org> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > Incidentally, the manual page says the br attribute is for a baud rate. > I'm pretty certain that, in the technical sense of the word, it's > actually talking about the bits-per-second rate. The word "rate" already implies "per unit of time". The word you are looking for is simply "bit rate". -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 15: 6:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 1283B37B69C for ; Wed, 21 Feb 2001 15:06:35 -0800 (PST) (envelope-from mi@misha.privatelabs.com) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id SAA23325; Wed, 21 Feb 2001 18:26:51 -0500 Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.1/8.11.1) with ESMTP id f1LN6Ov33309; Wed, 21 Feb 2001 18:06:25 -0500 (EST) (envelope-from mi@misha.privatelabs.com) Message-Id: <200102212306.f1LN6Ov33309@misha.privatelabs.com> Date: Wed, 21 Feb 2001 18:06:23 -0500 (EST) From: mi@aldan.algebra.com Subject: Re: cvs commit: src/share/mk sys.mk To: Kris Kennaway Cc: arch@freebsd.org In-Reply-To: <20010221123835.A59024@mollari.cthul.hu> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Feb, Kris Kennaway wrote: = On Wed, Feb 21, 2001 at 01:27:54PM -0500, mi@aldan.algebra.com wrote: = > BTW, may be -mcpu=${MACHINE_CPU} can be added to the default CFLAGS = > now? And a comment, that changing -mcpu to -march will, probably, be = > even better, but will prevent the binaries from being usable on = > earlier CPUs. [...] = The -march statement doesnt matter though, since some binaries built = with MACHINE_CPU set will already be CPU-specific (e.g. if you specify = i686 then openssl will use the i686 blowfish code) This means, the released binaries will never be compiled with this optimizations (since they are expected to run on all architectures). And that means, people doing benchmarks of the "out of the box" installations, will find FreeBSD slower for "secure web-hosting". Unless, of course, we provide different binaries on CDs. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 15:18:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 7853A37B401 for ; Wed, 21 Feb 2001 15:18:28 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A446666F32; Wed, 21 Feb 2001 15:18:27 -0800 (PST) Date: Wed, 21 Feb 2001 15:18:27 -0800 From: Kris Kennaway To: mi@aldan.algebra.com Cc: Kris Kennaway , arch@freebsd.org Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221151827.A61818@mollari.cthul.hu> References: <20010221123835.A59024@mollari.cthul.hu> <200102212306.f1LN6Ov33309@misha.privatelabs.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102212306.f1LN6Ov33309@misha.privatelabs.com>; from mi@aldan.algebra.com on Wed, Feb 21, 2001 at 06:06:23PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2001 at 06:06:23PM -0500, mi@aldan.algebra.com wrote: > On 21 Feb, Kris Kennaway wrote: > =3D On Wed, Feb 21, 2001 at 01:27:54PM -0500, mi@aldan.algebra.com wrote: > =3D > BTW, may be -mcpu=3D${MACHINE_CPU} can be added to the default CFL= AGS > =3D > now? And a comment, that changing -mcpu to -march will, probably, be > =3D > even better, but will prevent the binaries from being usable on > =3D > earlier CPUs. > [...] > =3D The -march statement doesnt matter though, since some binaries built > =3D with MACHINE_CPU set will already be CPU-specific (e.g. if you specify > =3D i686 then openssl will use the i686 blowfish code) >=20 > This means, the released binaries will never be compiled with this > optimizations (since they are expected to run on all architectures). > And that means, people doing benchmarks of the "out of the box" > installations, will find FreeBSD slower for "secure web-hosting". That's right. Until we stop supporting the 386 we have to provide 386-compatible binaries. > Unless, of course, we provide different binaries on CDs. This is possible, but space is obviously a problem. Kris --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lEzDWry0BWjoQKURAmKPAJ0buvowVs4qEfkwpBhslY4NRCaMggCg4TY2 CvArpPGkyofDj5HGQR4kAGA= =xqx7 -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 15:30:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 28E3037B503 for ; Wed, 21 Feb 2001 15:30:50 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f1LNUbc20336; Wed, 21 Feb 2001 15:30:37 -0800 Date: Wed, 21 Feb 2001 15:30:37 -0800 From: Brooks Davis To: Kris Kennaway Cc: mi@aldan.algebra.com, arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221153037.A16193@Odin.AC.HMC.Edu> References: <20010221123835.A59024@mollari.cthul.hu> <200102212306.f1LN6Ov33309@misha.privatelabs.com> <20010221151827.A61818@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010221151827.A61818@mollari.cthul.hu>; from kris@obsecurity.org on Wed, Feb 21, 2001 at 03:18:27PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2001 at 03:18:27PM -0800, Kris Kennaway wrote: > > This means, the released binaries will never be compiled with this > > optimizations (since they are expected to run on all architectures). > > And that means, people doing benchmarks of the "out of the box" > > installations, will find FreeBSD slower for "secure web-hosting". >=20 > That's right. Until we stop supporting the 386 we have to provide > 386-compatible binaries. Given that GENERIC on -current doesn't support the 80386 anymore, it seems to me that we should probably be able to build releases with: MACHINE_CPU=3Di386 i486 If there's demand someone could create an 80386 release, but I suspect most people doing actual work on those are embeded system people who build their own worlds and thus are quite capable of setting MACHINE_CPU correctly. Obviously, we will have to ship 80386 compatable binaries for the entire life of the 4.x branch. -- Brooks P.S. Before you run off and start screaming about the lack if 80386 support in GENERIC since this is the first time you've heard of it, please, please, please read the relevent archives for -current, -hacker, -arch, and -smp. Yes, that's a lot to read, but a lot of ground has been covered and there are solid reasons for this change. --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6lE+cXY6L6fI4GtQRAkilAJ9TIUn0Cs6oGOHKl5ca1EpL33Gm0QCgqwAs P03Qx3k13k8uSkD20vp7i3s= =yh0u -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 17:29:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0643837B4EC for ; Wed, 21 Feb 2001 17:29:09 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M1SbW01360; Wed, 21 Feb 2001 18:28:38 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220128.f1M1SbW01360@harmony.village.org> To: Brooks Davis Subject: Re: cvs commit: src/share/mk sys.mk Cc: Kris Kennaway , mi@aldan.algebra.com, arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Feb 2001 15:30:37 PST." <20010221153037.A16193@Odin.AC.HMC.Edu> References: <20010221153037.A16193@Odin.AC.HMC.Edu> <20010221123835.A59024@mollari.cthul.hu> <200102212306.f1LN6Ov33309@misha.privatelabs.com> <20010221151827.A61818@mollari.cthul.hu> Date: Wed, 21 Feb 2001 18:28:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010221153037.A16193@Odin.AC.HMC.Edu> Brooks Davis writes: : Given that GENERIC on -current doesn't support the 80386 anymore, it : seems to me that we should probably be able to build releases with: : : MACHINE_CPU=3Di386 i486 : : If there's demand someone could create an 80386 release, but I suspect : most people doing actual work on those are embeded system people who : build their own worlds and thus are quite capable of setting MACHINE_CPU : correctly. Obviously, we will have to ship 80386 compatable binaries : for the entire life of the 4.x branch. Your example is inconsistant with what you said. This example will build i386 and i486 binaries. I don't think it will help us much to do this, except for crypto. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 17:46:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id DA55A37B401 for ; Wed, 21 Feb 2001 17:46:07 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f1M1k1W15051; Wed, 21 Feb 2001 17:46:01 -0800 Date: Wed, 21 Feb 2001 17:46:01 -0800 From: Brooks Davis To: Warner Losh Cc: Kris Kennaway , mi@aldan.algebra.com, arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221174601.A9511@Odin.AC.HMC.Edu> References: <20010221153037.A16193@Odin.AC.HMC.Edu> <20010221123835.A59024@mollari.cthul.hu> <200102212306.f1LN6Ov33309@misha.privatelabs.com> <20010221151827.A61818@mollari.cthul.hu> <20010221153037.A16193@Odin.AC.HMC.Edu> <200102220128.f1M1SbW01360@harmony.village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102220128.f1M1SbW01360@harmony.village.org>; from imp@harmony.village.org on Wed, Feb 21, 2001 at 06:28:37PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2001 at 06:28:37PM -0700, Warner Losh wrote: > In message <20010221153037.A16193@Odin.AC.HMC.Edu> Brooks Davis writes: > : Given that GENERIC on -current doesn't support the 80386 anymore, it > : seems to me that we should probably be able to build releases with: > :=20 > : MACHINE_CPU=3D3Di386 i486 > :=20 > : If there's demand someone could create an 80386 release, but I suspect > : most people doing actual work on those are embeded system people who > : build their own worlds and thus are quite capable of setting MACHINE_CPU > : correctly. Obviously, we will have to ship 80386 compatable binaries > : for the entire life of the 4.x branch. >=20 > Your example is inconsistant with what you said. This example will > build i386 and i486 binaries. Setting MACHINE_CPU to "i386 i486" says that I will except i386 or i486 code in my binaries so there's a good chance they won't run on anything less the an i486. An actual 80386 would have to set MACHINE_CPU to "i386" because no other extension will actually work. Admittidly, this won't really help much with openssl since it appears to only have 586 and 686 assembly, but if there were 486 code, there's not reason I can see not to take advantage of that in the release builds since an 80386 won't boot from the CD anyway. In some ways, I think it would be nice to have a variable we could set to the actual CPU we are compiling to that would fill in MACHINE_CPU correctly. I suppose appropriate comments in /etc/defaults/make.conf would also be a reasionable substitute. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6lG9YXY6L6fI4GtQRAv6kAJ9XnmRL4iaJ4kOEGo1trC6E1qYRrQCfXGwn NqeIWZ0LAEddK22sgbzRAqM= =fH8i -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 20:23:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 4178837B4EC for ; Wed, 21 Feb 2001 20:23:07 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id VAA17325; Wed, 21 Feb 2001 21:20:00 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAzEaO0H; Wed Feb 21 21:19:58 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA05547; Wed, 21 Feb 2001 21:23:02 -0700 (MST) From: Terry Lambert Message-Id: <200102220423.VAA05547@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: djb@cr.yp.to (D. J. Bernstein) Date: Thu, 22 Feb 2001 04:21:53 +0000 (GMT) Cc: arch@FreeBSD.ORG, djb@cr.yp.to In-Reply-To: <20010221103002.3475.qmail@cr.yp.to> from "D. J. Bernstein" at Feb 21, 2001 10:30:02 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi; I stand by my evaluation. I don't think it's suitable code for many applications which I find interesting or necessary. People pressed me for my reasons above and beyond just the license; I gave them. Unlike others, I have not attacked you personally, either on this list, nor on the namedroppers list (the IETF DNSEXT working group, for those of you on the sidelines). As always, ignoring the emotional loading, your comments are interesting and thought provoking. > 1. Ever heard of citysearch.com? All their DNS records are published by > djbdns. Thousands more sites have switched to djbdns. One site is using > djbdns to publish records for hundreds of thousands of *.com's. > > But Terry claims that djbdns is suitable only for ``trivial uses.'' Wow. Your example shows volume, not reconfiguration complexity. Trivial is the opposite of complex; I use it as a technical term to describe the problem space for which DJBDNS is capable of mapping soloutions. BIND and Sendmail are large and complex, but in that complexity lies the majority of their utility. For what I was building, DJBDNS could not work without modification, and the modified code could not be distributed or sold afterward. I accept your right to license your code how you see fit, of course, but for me, that constrint was a show-stopper. > 2. It takes just a few seconds for tinydns-data to rebuild a typical > 10000-zone database and for rsync to push new data to secondaries. > > In contrast, for the same number of zones, BIND waits an average of > about 7 _minutes_ before it sends NOTIFY. Terry is wrong when he claims > that there's no latency with BIND; there is, in fact, massive latency. The design uses DNSUPDAT; I am _not_ engaging in rebuilds of the zones. I can not do this with DJBDNS, since it does not support DNSUPDAT. As discussed on namedroppers, I have relaxed the unjustified restriction against zone creation via DNSUPDAT, and I have a workable approach using a DNSSEC based security association for zone creation in the secondary, via DNSNOT. If I merely poke new data into the server, the NOTIFY is sent immediately, without a HUP, and without incurring a delay (on the system I was using, a 10,000 domain reload was ~45 seconds in BIND, not 7 minutes; since I'm not reloading, though, it really doesn't matter). > 3. The necessary use of rsync is a straightforward one-line command in > /service/tinydns/root/Makefile, as shown in the djbdns documentation. > Terry is wrong when he claims that ``synchronization is left as an > exercise for the student.'' The problem with this is not the method, it's the scripting necessary to synchronize multiple servers, and to retry in the case of a point to point connectivity failure between one system which has been updated, and one which has not. There were additional constraints on what ports would be passed through a state maintaining firewall, but that was an administrative barrier for me alone, and not really germane to the discussion. > 4. A new tinydns database atomically replaces the previous database. > The server switches to the new database for the next query. > > Terry is wrong when he claims that tinydns ``must be restarted for the > updates to take effect.'' He is wrong when he claims that frequent > updates would result in the server being ``largely unavailable.'' > > (Terry is also wrong when he implies that restarts are slow. Starting or > restarting tinydns takes a tiny fraction of a second. But this is a side > issue; there is _no_ outage when a database is updated.) 1200 machines calling in once an hour, with an update on connection setup and an update on connection teardown. is an update every 1.5 seconds. This assumes that the traffic is non-bursty. Using your numbers, which differ significantly from my benchmarks of the code on AIX, I still can't solve my update problem with DJBDNS. A large ISP trying to do something similar with their RADIUS IP assignments has only one choice at present, Microsoft's IAS (Internet Access Server), which integrates IP address assignment with DNS updates. For relatively static data, DJBDNS is probably fine; for more dynamic data, it's not. > 5. I have gone to great lengths to support DNS administration protocols. > For example, I designed the tinydns data format to be very easily > editable by external programs. Terry is wrong when he claims that I am > ``opposed to protocol level modification of DNS server contents.'' > > However, I do oppose Microsoft-style ``embrace and extend'' tactics. The > big problem with the BIND modification protocol is that the protocol was > (deliberately!) wedged into port 53. This is extremely inconvenient for > modular servers. This is actually the first time I've seen this objection tendered. It's a valid technical objection: most extensions, including DNSUPDAT _do_ operate over port 53. My suggestion, which you are probably not going to like, would be to use UNIX domain sockets and do descriptor passing; the alternative would be to set close on exec for all but the connection of interest, and exec a second program to do the work, or to rearchitect the server so that the modularization was on shared object, rather than programatic boundaries. Yes, I realize that these approaches would not work on some platforms where running DJBDNS might be desirable. As an ugly hack, you could make a connection from the "owner" of port 53 to the other program, and proxy the traffic. I wish you had raised this objection this baldly when DNSUPDAT was being discussed on namedroppers, rather than just calling it a bad idea. I think the other people would have been receptive to the idea of permitting the use of an alternate port as well as a port 53 piggyback. I certainly would have. I personally _must_ have the piggyback, due to firewall constraints on other traffic. I think it would be easy to seperate this out, still, if you wanted to bring this up in terms of DNS extensions having the possibility of different SRV records. A lot of your past arguments make a lot more sense in this context; frankly, I've never bought the "more programs are automatically more secure than less programs" philosophy, and it never really occurred to me that this would end up having implications for some implementation, when adding more operations over port 53. I personally stand by my namedroppers statements to the effect that I think all DNS data should be manipulable and retrievable over a single chokepoint, but I have sympathy for your problem, and I don't think it reasonable to architect a design which precludes a particular approach, with justification. > 6. I designed the djbdns server architecture so that one could easily > write servers using different types of databases. Look at tinydns and > rbldns and walldns (and pickdns, though tinydns now has the same > features) in the package. Or look at Bruce Guenter's sqldjbdns. > > Terry is wrong when he claims that I am ``strongly opposed to offering > alternate back ends.'' There is no truth to Terry's insinuations that I > rejected Terry's SQL ideas. There is also no truth to the similar > insinuations from Jack Rusher and Wes Peters. In fact, as far as I can > tell, these people have _never_ sent any email to the dns mailing list. Let me put this in context; my own servers that I care about these days are running out of an LDAP directory, not an SQL database; I'm personally not interested in using an SQL server. I think this would meet your "not in the protocol" objection an ability to programmatically update the data being served. Something which would result in people taking you much more seriously would be if the license was relaxed on the default back end or a stubbed out back end. > 6. Before tinydns (or dnscache) sees any untrusted data, it chroots and > drops privileges. Inserting an exec at this point would have no security > benefits and would turn installation into a chroot-BIND-style nightmare. > Terry is being silly when he says that ``you have to wonder'' about the > lack of an exec. When security is at issue, the less actual code that has privileges (even if they are later dropped), the better. My point was one of "in for a penny, in for a pound". I was not trying to be silly, I was attempting to express cynicism about where the line was drawn. > 7. djbdns is highly modular. Almost all of the program-level modules, > and many of the internal C functions, are thoroughly documented on my > web pages; Matt is wrong when he says ``the code is uncommented.'' > > For further discussion of code readability, see my bugtraq postings on > the Dijkstra phenomenon. Note that I did not complain about the readability of the code; I personally don't mind running "indent", and would have been happy had FreeBSD integrated it into the CVS checkin process so that people could quit complaining about where other people put their braces. I'd actually appreciate a pointer to the postings on bugtraq, if you have one; otherwise it will take me a while to get around to searching them out myself. Regards, 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-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21: 6: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 10DA337B491 for ; Wed, 21 Feb 2001 21:05:58 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M54rW02728; Wed, 21 Feb 2001 22:04:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220504.f1M54rW02728@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: DJBDNS vs. BIND Cc: Cedric Berger , Terry Lambert , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 19 Feb 2001 18:27:15 PST." <200102200227.f1K2RHv02933@cwsys.cwsent.com> References: <200102200227.f1K2RHv02933@cwsys.cwsent.com> Date: Wed, 21 Feb 2001 22:04:53 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102200227.f1K2RHv02933@cwsys.cwsent.com> Cy Schubert - ITSD Open Systems Group writes: : > If I remember my old university days, our VAX 11/780 had something : > very simmilar... : : That makes sense. Dave Cutler, chief NT architect, worked on VMS for : DEC. VMS did not have a registry. It did have a lot of binary files, but didn't have a registry. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21: 7:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0302237B491 for ; Wed, 21 Feb 2001 21:07:44 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M56LW02750; Wed, 21 Feb 2001 22:06:21 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220506.f1M56LW02750@harmony.village.org> To: Cedric Berger Subject: Re: DJBDNS vs. BIND Cc: Wes Peters , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 19 Feb 2001 21:39:14 PST." <3A920302.D750332F@wireless-networks.com> References: <3A920302.D750332F@wireless-networks.com> <200102200227.f1K2RHv02933@cwsys.cwsent.com> <3A9200C6.AA3C8433@softweyr.com> Date: Wed, 21 Feb 2001 22:06:21 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A920302.D750332F@wireless-networks.com> Cedric Berger writes: : Well, the windows registry also provide such kind of centralized, : persistent environment variables, with different namespaces : (per system, per user)? : : At least, let's say that Windows way of storing configuration looks : closer then VMS than UNIX. It does not look anything like VMS. At least nothing I ever saw in VMS in the 6 years I used it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21:10:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0F9D537B4EC for ; Wed, 21 Feb 2001 21:10:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M5AOW02789; Wed, 21 Feb 2001 22:10:24 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220510.f1M5AOW02789@harmony.village.org> To: Kris Kennaway Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 01:15:48 PST." <20010220011548.A34873@mollari.cthul.hu> References: <20010220011548.A34873@mollari.cthul.hu> Date: Wed, 21 Feb 2001 22:10:24 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010220011548.A34873@mollari.cthul.hu> Kris Kennaway writes: : What does this list think about the merits of this idea? ... : add getprogname() and setprogname(). These allow uses of __progname to : be wrapped in some sane fashion, for portability. I like it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21:10:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A4D5F37B401 for ; Wed, 21 Feb 2001 21:10:53 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M59ZW02769; Wed, 21 Feb 2001 22:09:35 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220509.f1M59ZW02769@harmony.village.org> To: Wes Peters Subject: Re: DJBDNS vs. BIND Cc: Cedric Berger , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 19 Feb 2001 23:45:50 MST." <3A92129E.7CD722F4@softweyr.com> References: <3A92129E.7CD722F4@softweyr.com> <200102200227.f1K2RHv02933@cwsys.cwsent.com> <3A9200C6.AA3C8433@softweyr.com> <3A920302.D750332F@wireless-networks.com> Date: Wed, 21 Feb 2001 22:09:35 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A92129E.7CD722F4@softweyr.com> Wes Peters writes: : The logicals on VMS were stored only in memory, and were created during : or after system boot by DSL procedures, the equivalent of shell scripts. : This is actually much more like UNIX than the Windows Registry. DCL wes. It was the DCL startup scripts that setup the logical variables. But they almost always contained paths to files, and rarely did they contain configuration information. These were usually codified in config files rather than in logical names (although there were some exceptions). The main reason for this was speed. It was faster to read RMS databases than to parse a bunch of logicals. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21:17:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 9959437B4EC for ; Wed, 21 Feb 2001 21:17:11 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DFE8066F2E; Wed, 21 Feb 2001 21:17:10 -0800 (PST) Date: Wed, 21 Feb 2001 21:17:10 -0800 From: Kris Kennaway To: Brooks Davis Cc: Warner Losh , Kris Kennaway , mi@aldan.algebra.com, arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010221211710.A67348@mollari.cthul.hu> References: <20010221153037.A16193@Odin.AC.HMC.Edu> <20010221123835.A59024@mollari.cthul.hu> <200102212306.f1LN6Ov33309@misha.privatelabs.com> <20010221151827.A61818@mollari.cthul.hu> <20010221153037.A16193@Odin.AC.HMC.Edu> <200102220128.f1M1SbW01360@harmony.village.org> <20010221174601.A9511@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221174601.A9511@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Wed, Feb 21, 2001 at 05:46:01PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 21, 2001 at 05:46:01PM -0800, Brooks Davis wrote: > > Your example is inconsistant with what you said. This example will > > build i386 and i486 binaries. Bad Warner, go and read the docs :) > In some ways, I think it would be nice to have a variable we could set > to the actual CPU we are compiling to that would fill in MACHINE_CPU > correctly. I suppose appropriate comments in /etc/defaults/make.conf > would also be a reasionable substitute. Can you see a problem with what's in there now? # MACHINE_CPU controls which processor-specific optimizations will be # used by certain components of FreeBSD (currently only OpenSSL). # This should be set to a list of your CPU type, plus all previous # generations of the CPU architecture. The reason for using a list is # because not all programs which use the MACHINE_CPU variable may have # optimizations for your specific CPU generation (e.g. Pentium Pro), # but may have optimizations for the previous generation (e.g. Pentium). # Currently only the following CPU generations are used: # i686 i585 i386 # #MACHINE_CPU=i686 i586 i386 Kris --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lKDWWry0BWjoQKURAgvbAJ9ZmRSutHeroiiQ/FGJ06qMO2UUWQCgtdON 1Oml4ES5K3lQ7lizVE4KTac= =FF1/ -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21:25:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6918737B401; Wed, 21 Feb 2001 21:25:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1M5P9W02890; Wed, 21 Feb 2001 22:25:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220525.f1M5P9W02890@harmony.village.org> Subject: Re: The whole libc thing. To: Stephen McKay , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 21:03:31 +1000." <200102201103.f1KB3VC19818@dungeon.home> References: <200102201103.f1KB3VC19818@dungeon.home> <200102191217.f1JCHno13825@dungeon.home> <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> <200102191734.f1JHYQW61198@harmony.village.org> Date: Wed, 21 Feb 2001 22:25:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ I don't think I've replied to this [[ In message <200102201103.f1KB3VC19818@dungeon.home> Stephen McKay writes: : There have never been macros that use _up, and I can't see any reason : for nasty FILE-grovelling programs to use _up. Should be safe. Good. That was my reading as well. : >We've added : >symbols like this in the past for various reasons, but maybe never so : >late in the 3.x branch. We also have the technology to regenerate the : >libc.so.[34] in place if we needed to w/o recompiling, but polishing : >it for the great masses will take some time. : : Ah, I see. You fix the problem by fixing all copies of libc, which in : this case is really just two versions. This has two interesting results: : people who don't upgrade anything at all can enjoy their ignorance in : peace, and those who upgrade something causing it to break, can be told : to install a compatible hacked libc, which fixes their current problem : and all future problems (to do with FILE). Right. : But that only gets you through part one. When part two (FILE becomes : radically incompatible) arrives, what then? Old binaries and/or : libraries will always want to see __sF, and will pass around pointers : into __sF. Will libc forever after translate &__sF[1] to __stdout? : How could it hope to support old binaries that fiddle with the insides : of FILE? It can't. I predict that these binaries will be orphaned. FILE won't become radically incompatible without a major version bump of everything. Libc will, for the libc.so.5 series, define it, but not past that. FILE has to have a stable first 88 bytes, or we have to bump all shared major version numbers. It can grow, once we take the 88 out of the __sF[] stuff. : >After talking with Peter on IRC extensively about this, I think that : >we need a bigger window where we generate __stdout before trying to : >take the plunge. There are still too many libraries that depend on : >__sF. : : Do I read this as "keep the hack in place long enough so that every : binary anyone cares about has been recompiled"? If so, I think this : is going the wrong way. If we are going for a global recompile, it : should be explicit, but not in a way that overwrites existing libraries. I think we disagree on this. In the end you may be right, but the prospect of forcing a major bump on all the libraries in ports was beyond my idea of a reasonable change. : Oh, and earlier I forgot to highlight your comment: "This is easy to fix. : Just rebuild the port that produced libfred.so.3." This implies that : recompiling a lot of stuff is central to your plans. I claim that we : can make this recompiling explicit and safe to all past and future : binaries by equating this recompile with a major version bump. Everywhere. This may be true. The other reason that I worried about bumping all the major numbers in all the ports is the effect on the current/stable split. We'd need different versions for stable and current on all the ports, and all the depends and such. i don't see a good way of doing that. We encode major numbers all over the place in /usr/ports/*/*/Makefile, but for the major that we generate, as well as the LIBDEPENDS. It would be a nightmare to support two versions in all of them. : Lastly, I'm happy that urgent commits have slowed, and we can work this : out at a more civilized pace. Yes. I wanted to get this over, but you are right that we need to think about this more. I fear that we'll end up with the least evil of many evil choices. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 21 21:29:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8998F37B503 for ; Wed, 21 Feb 2001 21:29:49 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1M5TXW60848; Wed, 21 Feb 2001 21:29:33 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Feb 2001 21:29:33 -0800 (PST) From: Matt Dillon Message-Id: <200102220529.f1M5TXW60848@earth.backplane.com> To: Terry Lambert Cc: djb@cr.yp.to (D. J. Bernstein), arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102220423.VAA05547@usr05.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ::.... : ::.. :::.... :Hi; : :I stand by my evaluation. I don't think it's suitable code for :... Hey Warner, pass the popcorn! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 2:58:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5946337B401 for ; Thu, 22 Feb 2001 02:58:12 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA26769; Thu, 22 Feb 2001 21:58:05 +1100 Date: Thu, 22 Feb 2001 21:50:13 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk In-Reply-To: <20010221124552.A59188@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Feb 2001, Kris Kennaway wrote: > On Wed, Feb 21, 2001 at 11:48:05AM -0800, David O'Brien wrote: > > On Wed, Feb 21, 2001 at 01:27:54PM -0500, mi@aldan.algebra.com wrote: > > > BTW, may be -mcpu=${MACHINE_CPU} can be added to the default CFLAGS now? > > > > I am nervous about this on the Alpha unless very well tested. We all > > know that an ev4 system as the ev4 cannot handled ev56-only instructions. > > This applies to the i386 as well (i386 can't handle i586 instructions) -mcpu doesn't affect the instruction set used on i386's. It takes -march to affect it. Similarly for many other target machines. The alpha seems to be different here (it doesn't have -march). Our MACHINE, MACHINE_ARCH and MACHINE_CPU are sort rotated compared with the gcc -march and -mcpu: MACHINE is similar to -march MACHINE_ARCH is similar to -mcpu MACHINE_CPU is more specialized Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 3:51:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id DA2DA37B503; Thu, 22 Feb 2001 03:51:37 -0800 (PST) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp74.dyn249.pacific.net.au [203.143.249.74]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id WAA11961; Thu, 22 Feb 2001 22:51:34 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.11.1) with ESMTP id f1MBrFm23661; Thu, 22 Feb 2001 21:53:15 +1000 (EST) (envelope-from mckay) Message-Id: <200102221153.f1MBrFm23661@dungeon.home> To: Warner Losh Cc: Stephen McKay , arch@FreeBSD.ORG Subject: Re: The whole libc thing. References: <200102201103.f1KB3VC19818@dungeon.home> <200102191217.f1JCHno13825@dungeon.home> <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> <200102191734.f1JHYQW61198@harmony.village.org> <200102220525.f1M5P9W02890@harmony.village.org> In-Reply-To: <200102220525.f1M5P9W02890@harmony.village.org> from Warner Losh at "Wed, 21 Feb 2001 22:25:09 -0700" Date: Thu, 22 Feb 2001 21:53:15 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 21st February 2001, Warner Losh wrote: >In message <200102201103.f1KB3VC19818@dungeon.home> Stephen McKay writes: >: Oh, and earlier I forgot to highlight your comment: "This is easy to fix. >: Just rebuild the port that produced libfred.so.3." This implies that >: recompiling a lot of stuff is central to your plans. I claim that we >: can make this recompiling explicit and safe to all past and future >: binaries by equating this recompile with a major version bump. Everywhere. > >This may be true. I'm concerned that we will make the situation worse by hackery. If people go around recompiling libraries (especially ports), then when the cutover comes we will have some libFOO.so.N with the hacks, and some without. That could be a lot harder to support than having them all without any hacks. On the other hand, I'm not sure the current hacks cause any problem. Some of the proposed hacks would have, though. We'll see what happens. >The other reason that I worried about bumping all the major numbers in >all the ports is the effect on the current/stable split. We'd need >different versions for stable and current on all the ports, and all >the depends and such. i don't see a good way of doing that. We >encode major numbers all over the place in /usr/ports/*/*/Makefile, >but for the major that we generate, as well as the LIBDEPENDS. It >would be a nightmare to support two versions in all of them. That does look nasty. It seems that whatever huge change appears in -current will have to be quickly replicated in -stable. That's not good either. If I think of a good solution to this, I'll get back to you. >I fear that we'll end up with the least evil of many evil choices. There are a great many evil possibilities here. I'm not yet confident that we will select the least evil. Some evil has been incorporated already. I think, even now, given total veto power, :-) that I would back out the stdio locking changes entirely, until we knew how to proceed without danger. Stephen. PS I think it's safe again to mail to my ISP account, though I haven't been able to find out why your earlier mail spent a month on their server. Maybe mail to both of my addresses? :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 4:59:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 967F037B503 for ; Thu, 22 Feb 2001 04:59:30 -0800 (PST) (envelope-from netchild@leidinger.net) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14VvLF-0005Nw-00; Thu, 22 Feb 2001 13:59:29 +0100 Received: from a2a16.pppool.de ([213.6.42.22] helo=Magelan.Leidinger.net) by mx3.freenet.de with esmtp (Exim 3.22 #1) id 14VvLD-00060F-00; Thu, 22 Feb 2001 13:59:27 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.2/8.11.2) with ESMTP id f1MBopF07996; Thu, 22 Feb 2001 12:50:52 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200102221150.f1MBopF07996@Magelan.Leidinger.net> Date: Thu, 22 Feb 2001 12:50:50 +0100 (CET) From: Alexander Leidinger Subject: Re: cvs commit: src/share/mk sys.mk To: kris@obsecurity.org Cc: arch@FreeBSD.ORG In-Reply-To: <20010221123835.A59024@mollari.cthul.hu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Feb, Kris Kennaway wrote: > .if ${MACHINE_CPU:Mi686} > CFLAGS += -mpentiumpro > .elif ${MACHINE_CPU:Mi586} > CFLAGS += -mpentium > ... > .endif > > which may be worthwhile to do. > > The -march statement doesnt matter though, since some binaries built > with MACHINE_CPU set will already be CPU-specific (e.g. if you specify > i686 then openssl will use the i686 blowfish code) You want to use "-mXXX -march=XXX". You are CPU-specific already, no need to produce parts of code which run on an i386 too. ---snip--- #include int main(void) { #if defined(__pentiumpro__) || defined(__i686__) puts("pentiumpro"); #endif #if defined(__pentium__) || defined(__i586__) puts("pentium"); #endif exit(0); } ---snip--- ---snip--- (23) netchild@ttyp0 % rm cputest; CFLAGS=-mpentiumpro gmake cputest; md5 cputest; ./cputest cc -mpentiumpro cputest.c -o cputest MD5 (cputest) = 577769bb73460f7bd062882a4ee44235 pentiumpro (24) netchild@ttyp0 % rm cputest; CFLAGS=-march=pentiumpro gmake cputest; md5 cputest; ./cputest cc -march=pentiumpro cputest.c -o cputest MD5 (cputest) = b721209c7b0089ee1442cb0880af06b8 (25) netchild@ttyp0 % rm cputest; CFLAGS="-mpentiumpro -march=pentiumpro" gmake cputest; md5 cputest; ./cputest cc -mpentiumpro -march=pentiumpro cputest.c -o cputest MD5 (cputest) = c41ce5e5941b335c6fcf1b6d8d59f2e1 pentiumpro ---snip--- Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 12:55:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 337CE37B401 for ; Thu, 22 Feb 2001 12:55:53 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C80E766C34; Thu, 22 Feb 2001 12:55:52 -0800 (PST) Date: Thu, 22 Feb 2001 12:55:52 -0800 From: Kris Kennaway To: Alexander Leidinger Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010222125552.B6517@mollari.cthul.hu> References: <20010221123835.A59024@mollari.cthul.hu> <200102221150.f1MBopF07996@Magelan.Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102221150.f1MBopF07996@Magelan.Leidinger.net>; from Alexander@leidinger.net on Thu, Feb 22, 2001 at 12:50:50PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2001 at 12:50:50PM +0100, Alexander Leidinger wrote: > On 21 Feb, Kris Kennaway wrote: >=20 > > .if ${MACHINE_CPU:Mi686} > > CFLAGS +=3D -mpentiumpro > > .elif ${MACHINE_CPU:Mi586} > > CFLAGS +=3D -mpentium > > ... > > .endif > >=20 > > which may be worthwhile to do. > >=20 > > The -march statement doesnt matter though, since some binaries built > > with MACHINE_CPU set will already be CPU-specific (e.g. if you specify > > i686 then openssl will use the i686 blowfish code) >=20 > You want to use "-mXXX -march=3DXXX". You are CPU-specific already, no > need to produce parts of code which run on an i386 too. Hmm, that's not what's documented in the gcc info docs. `-march=3DCPU TYPE' Generate instructions for the machine type CPU TYPE. The choices for CPU TYPE are the same as for `-mcpu'. Moreover, specifying `-march=3DCPU TYPE' implies `-mcpu=3DCPU TYPE'. `-m386' `-m486' `-mpentium' `-mpentiumpro' Synonyms for -mcpu=3Di386, -mcpu=3Di486, -mcpu=3Dpentium, and -mcpu=3Dpentiumpro respectively. These synonyms are deprecated. Kris --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lXzYWry0BWjoQKURAlK6AJ49Sn5EGdd3oD79hnAUHOIfLoyPOwCgnWkc GZTJmOtmMVHNl81UMsa2lD8= =9u/z -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 12:57:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id EB0C537B401 for ; Thu, 22 Feb 2001 12:57:56 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AF90C66C34; Thu, 22 Feb 2001 12:57:56 -0800 (PST) Date: Thu, 22 Feb 2001 12:57:56 -0800 From: Kris Kennaway To: Brooks Davis Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/share/mk Makefile Message-ID: <20010222125756.C6517@mollari.cthul.hu> References: <200102221122.f1MBMlk67663@freefall.freebsd.org> <20010222115542.A22711@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010222115542.A22711@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Feb 22, 2001 at 11:55:42AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 22, 2001 at 11:55:42AM -0800, Brooks Davis wrote: > This all looks good. It's exactly what I was wishing for on the > previous thread. One minor issue though. Since there are MMX and > non-MMX Pentiums, there probably needs to be and MMX entry for > MACHINE_CPU and some sort of CPUTYPE for non-MMX Pentiums. I suspect a > vast number of old pentium systems turned routers are non-MMX. I think > the same holds true for SSE and i686 as well. Yep, I was thinking about that. There are some ports which have MMX code. Kris --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lX1TWry0BWjoQKURAs6+AJ9x50X/LUchgvxF5OCNcDBsgP9jNwCglSvI bqcPIoL6YPBxXlSlEr0QSX0= =yX4m -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 14: 9: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id ABE6137B491 for ; Thu, 22 Feb 2001 14:09:04 -0800 (PST) (envelope-from netchild@leidinger.net) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14W3v5-0007kk-00; Thu, 22 Feb 2001 23:09:03 +0100 Received: from b8420.pppool.de ([213.7.132.32] helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14W3v4-00039i-00; Thu, 22 Feb 2001 23:09:03 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.2/8.11.2) with ESMTP id f1MLrsf01077; Thu, 22 Feb 2001 22:53:56 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200102222153.f1MLrsf01077@Magelan.Leidinger.net> Date: Thu, 22 Feb 2001 22:53:52 +0100 (CET) From: Alexander Leidinger Subject: Re: cvs commit: src/share/mk sys.mk To: kris@obsecurity.org Cc: arch@FreeBSD.ORG In-Reply-To: <20010222125552.B6517@mollari.cthul.hu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 Feb, Kris Kennaway wrote: > On Thu, Feb 22, 2001 at 12:50:50PM +0100, Alexander Leidinger wrote: >> On 21 Feb, Kris Kennaway wrote: >> >> > .if ${MACHINE_CPU:Mi686} >> > CFLAGS += -mpentiumpro >> > .elif ${MACHINE_CPU:Mi586} >> > CFLAGS += -mpentium >> > ... >> > .endif >> > >> > which may be worthwhile to do. >> > >> > The -march statement doesnt matter though, since some binaries built >> > with MACHINE_CPU set will already be CPU-specific (e.g. if you specify >> > i686 then openssl will use the i686 blowfish code) >> >> You want to use "-mXXX -march=XXX". You are CPU-specific already, no >> need to produce parts of code which run on an i386 too. > > Hmm, that's not what's documented in the gcc info docs. The docs are wrong. > `-march=CPU TYPE' > Generate instructions for the machine type CPU TYPE. The choices > for CPU TYPE are the same as for `-mcpu'. Moreover, specifying > `-march=CPU TYPE' implies `-mcpu=CPU TYPE'. That's not true, test it on your own (see my previous mail with my test program) if you think the doc is right (or have a look at "man gcc" on a system with gcc 2.95.3 (e.g. a recent -current)). Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 20:50:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 57AAB37B401 for ; Thu, 22 Feb 2001 20:50:26 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14VQDJ-0000Gz-00; Tue, 20 Feb 2001 20:45:13 -0700 Message-ID: <3A9339C9.C23CBC04@softweyr.com> Date: Tue, 20 Feb 2001 20:45:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Jonathan Lemon , arch@freebsd.org Subject: Re: DJBDNS vs. BIND References: <200102202116.OAA27627@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > It would be fairly trivial to monitor a configuration file with kevent, > > which would generate a notice whenever the file is changed/copied/renamed, > > etc. I believe that John-Mark Gurney had patches somewhere to implement > > exactly this for inetd. > > > > The problem is that under our current model, the administrators do not > > expect writes to the file to take immediate effect, and this immediately > > breaks POLA. So while it could be done, it may not be a good idea. At > > the very least, I would argue that it should be hidden behind a flag option. > > This is what makes something with an API a better bet, since > you can define it to be a semantic of the API. That prevents > a POLA violation. > > I like that people are willing to at least discuss using a new > API that isn't implemented everywhere; many of the system calls > we have today started out that way, too, and it was use, which > proved their utility, which propelled them to the level of a > standard. Given that we have kqueue monitoring for files, I'd suggested an otherwise unused file flag and a chflags command to twiddle it. A daemon could monitor for changes to the "config" flag and re-read the file upon this event; the administrator could simple "chflags config /etc/inetd.conf" to notify anyone interested that inetd.conf has been changed and should now work. > Lets not hamstring ourselves over having to hide such a fundamental > improvement behind a flag, before we even know the shapes it might > take. We'll have the rest of time to be self limiting, after we > figure out what it should look like. 8-). Or, rather than hiding them behind a change in an otherwise unrelated flag, put one up there that means exactly what we're asking for. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 20:50:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 2606337B503 for ; Thu, 22 Feb 2001 20:50:47 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14VQOT-0000H7-00; Tue, 20 Feb 2001 20:56:45 -0700 Message-ID: <3A933C7D.3E8D1265@softweyr.com> Date: Tue, 20 Feb 2001 20:56:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: Cedric Berger , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102202015.MAA77474@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rodney W. Grimes" wrote: > > > Cedric Berger wrote: > > > > > > > Configuration data > > > > on VMS was mostly stored in the form of "logical names", which are sort > > > > of like persistent environment variables with different namespaces (per > > > > system, per group, and per user). > > > > > > Well, the windows registry also provide such kind of centralized, > > > persistent environment variables, with different namespaces > > > (per system, per user)? > > > > > > At least, let's say that Windows way of storing configuration looks > > > closer then VMS than UNIX. > > > > OK, except VMS didn't store them in some half-baked database file, and > > didn't regularly scramble all of it. ;^) > > You never had to deal with a scrambled sysuaf.dat, rightlist.dat, > netproxy.dat or a million other ``registry like'' .dat files on VMS? > Your fortunate! (Yea, VMS was 10^6 times better about not doing this, > but it still did it, and one could usually easily recover by deleting > the highest version of the file (thank god for versions).) Mmm, good point. I'd forgotten about hacking into VMS 3.x systems by playing games with system logicals to make it find my sysuaf.dat and rightlist.dat on the next reboot. ;^) > > The logicals on VMS were stored only in memory, and were created during > > or after system boot by DSL procedures, the equivalent of shell scripts. > ^^^ DCL ^^^^^^^ freudian slip, I guess ;^) > > This is actually much more like UNIX than the Windows Registry. > > Take a look at ``DIR sys$system:*.dat'' some time and tell me that again... > LNM is only one part of the picture... Well, yeah, but the logicals are more like environment variables with name scopes than the Registry. The *.DAT files are more like a cross between /etc/passwd and a DBM database, something that lends itself to updates more easily than text files, but is a royal pain to deal with when the system is half-crippled. Personally, I've always liked the UNIX method of sticking with text files, even if it does make the programming somewhat more difficult. The worst is to come up with some half-baked compromise, like the ODM db on AIX, and all of the awful export/import BS they cobbled onto the side of that so traditional UNIX programs would (sort of) work on their half- breed (sort of) UNIX-ish system. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 20:51:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 2444137B4EC for ; Thu, 22 Feb 2001 20:51:11 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14VQxk-0000Hg-00; Tue, 20 Feb 2001 21:33:12 -0700 Message-ID: <3A934507.A0645CF3@softweyr.com> Date: Tue, 20 Feb 2001 21:33:11 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Randell Jesup Cc: Terry Lambert , Matt Dillon , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Randell Jesup wrote: > > Terry Lambert writes: > >> :> cached state data is inherently bad everywhere, not just in DNS > >> :> servers. > >> : > >> :You scare me, I was thinking just the same thing about mountd > >> :earlier today. Only problem is that it violates POLA(* heh), one > >> :could offer an command line option to have it watch the file. > >> > >> I was thinking just having a 'mountd -reload'. I don't like the > >> idea of programs polling configuration files. I actually used a > >> similar mechanism in Diablo and wound up having to add hacks to, > >> for example, try to avoid catching a configuration file in the middle > >> of being written out by an editor. > >> > >> A better way would be to take the 'vipw' concept and write a general > >> system utility to edit configuration files that does the right thing > >> when you write the config file out (heh heh... based on.... another > >> config file!). > > > >You could close the file in between polls, and reopen it O_EXCL; > >or your vipw suggestion would also work, using a two stage commit > >to ensure that it was all or nothing for changes. > > > >Really, the program wants to sit on the file as part of its select > >loop, and when the file is closed so that it's the sole opener again, > >get an "exceptional condition" flagged in the select. > > > >Barring that, the next best thing is a signal, and the next best > >after that is a poll. > > As an aside, we ran into this in AmigaDos as well. We cached all > of our preferences (configuration) data in ramdisk files (which hardly took > any space, since there was no block overhead, and guaranteed fast access). > I then added notification commands to the filesystem, so applications could > find out when the configuration changed. For fixed-size (binary) config > files, you could simply make a single read, which became a ram-to-ram copy > without very much overhead. For variable-sized files, a simple exclusive > open and then read would do. Since these were all ram-to-ram copies, and > the overhead on the Amiga of message passing and Open()/Read() was small, > it worked well. > > >In an ideal system, you would change the host name one place (for an > >example of commonly cached information), and everything would "just > >know" and "just do the right thing". > > There's still a synchronization problem, even if the hostname > is in shared memory, even if the write is atomic (a reader may be in the > middle of reading the string). > > >Having an external program watching the configuration file changes > >is really a very poor approach, since it doesn't address the > >underlying problem very well. > > True. > > >A registry-like configuration store, which was cached by the OS, > >and was referenced directly each time the data was needed, instead > >of allowing the programs to cache data which might change would > >really be the best approach, > > Fetching the data out of a kernel service on each access would be > (potentially) a pretty major hit, performance-wise. Some form of > registration of interest in the data would be better. Either something > like the Amiga (get a signal/message/callback/whatever when it changes, > then request the new information), or something that passes the > notification along with the new data. > > The downside is that to change the data, you must also go through > this procedure. The nice thing about the Amiga notification method was > that you could use any tool to modify a preference (configuration option) - > text editors, fancy GUI editors, copy (cp), etc. You could still provide > this behavior if you made this configuration cache also act as a virtual > FS, so you could call up (say) /config/hostname into vi, change it, then > just save it. Or just copy another file over the existing one, etc. This > kindof turns vipw on it's head. > > An alternative would be to leave everything in normal files, > extend the vipw schema to lock arbitrary files (configedit), and then hook > it into a notification method as per above. This loses the ability to use > something like cp, but it allows arbitrary text editors, and hooks can be > given to allow GUI programs to interact with a config file as well. > > > but I rather think that it would be > >rejected because Microsoft had the idea. Heh. A new way to screw > >over your competitors: make them so hateful that they refuse to > >learn from your good ideas, and have to come up with something > >gratuitously different (and probably more complicated) just to be > >able to say that they aren't like you... > > :-) We in the unix world have a well-founded aversion to storing configuration information in binary data stores that can't be accessed via ed(1) when the system is in single-user mode. If we wanted to stuff all the system configuration into such a black hole, we could've done it with DBM data- bases more than a decade ago, quite easily. Yeah, yeah, this coming from the guy who uses PgSQL to store application configuration data, but that box has no "single user mode", doesn't have ed(1) on it, and doesn't really have a console either. We are also smart enough to realize the difference between the piss-poor implementation of the registry versus the piss-poor design. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 23:19:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id B559037B503 for ; Thu, 22 Feb 2001 23:19:41 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 12443548 for ; Thu, 22 Feb 2001 23:19:21 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id XAA11558 for ; Thu, 22 Feb 2001 23:19:20 -0800 (PST) Message-ID: <3A960EF8.75C3FC53@cup.hp.com> Date: Thu, 22 Feb 2001 23:19:20 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: sysctl kern.fallback_elf_brand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm worried about the default value of the kern.fallback_elf_brand syctl (= 9 -> FreeBSD). It basicly tells the kernel that binaries without any branding are FreeBSD binaries. Since our binaries are always branded (AFAICT), this seems to me as the wrong default. One problem with this is that unbranded static Linux binaries are executed as FreeBSD native binaries and there's a high chance of them rebooting the machine if run as root. I think we need to disable the fallback ELF branding when no ABI compatibility module is loaded. Otherwise we can set the fallback to the one ABI module, or when multiple are loaded, the first. In the latter case, the first may not be the preferred one, so we probably need to have a bit more tuning than simply selecting the first. Of course, we can also set the default to 3 (=Linux) under the assumption that the Linuxulator is the most frequently used ABI module. Thoughts? -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 23:37:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 0B01837B4EC for ; Thu, 22 Feb 2001 23:37:55 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14WClD-000Nek-00; Fri, 23 Feb 2001 07:35:27 +0000 Date: Fri, 23 Feb 2001 07:35:26 +0000 From: Tony Finch To: Wes Peters Cc: Randell Jesup , Terry Lambert , Matt Dillon , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG, Tony Finch Subject: Re: DJBDNS vs. BIND Message-ID: <20010223073526.F19285@hand.dotat.at> References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A934507.A0645CF3@softweyr.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > >We in the unix world have a well-founded aversion to storing configuration >information in binary data stores that can't be accessed via ed(1) when >the system is in single-user mode. If we wanted to stuff all the system >configuration into such a black hole, we could've done it with DBM data- >bases more than a decade ago, quite easily. You mean like spwd.db? Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at FAIR ISLE FAEROES SOUTHEAST ICELAND: NORTH OR NORTHEAST 6 TO GALE 8, DECREASING 4 OR 5, BACKING NORTHWEST AND INCREASING 5 TO 7. WINTRY SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 23:38: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-188.dsl.lsan03.pacbell.net [63.207.60.188]) by hub.freebsd.org (Postfix) with ESMTP id 6744037B491 for ; Thu, 22 Feb 2001 23:38:01 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2B89066F38; Thu, 22 Feb 2001 23:38:01 -0800 (PST) Date: Thu, 22 Feb 2001 23:38:01 -0800 From: Kris Kennaway To: Marcel Moolenaar Cc: arch@FreeBSD.org Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010222233800.A1394@mollari.cthul.hu> References: <3A960EF8.75C3FC53@cup.hp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A960EF8.75C3FC53@cup.hp.com>; from marcel@cup.hp.com on Thu, Feb 22, 2001 at 11:19:20PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > Hi, >=20 > I'm worried about the default value of the kern.fallback_elf_brand syctl > (=3D 9 -> FreeBSD). It basicly tells the kernel that binaries without any > branding are FreeBSD binaries. Since our binaries are always branded > (AFAICT), this seems to me as the wrong default. >=20 > One problem with this is that unbranded static Linux binaries are > executed as FreeBSD native binaries and there's a high chance of them > rebooting the machine if run as root. >=20 > I think we need to disable the fallback ELF branding when no ABI > compatibility module is loaded. Otherwise we can set the fallback to the > one ABI module, or when multiple are loaded, the first. In the latter > case, the first may not be the preferred one, so we probably need to > have a bit more tuning than simply selecting the first. >=20 > Of course, we can also set the default to 3 (=3DLinux) under the > assumption that the Linuxulator is the most frequently used ABI module. >=20 > Thoughts? I've run into the unbranded Linux binary reboot before..very annoying. I agree the default should be changed. Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lhNYWry0BWjoQKURAqK6AJ4kCDIeOxCAQ9E7XmoRU0ZibQK3cwCeMrly /kdK33lIOIkjO6LyPT6QZQo= =2Qt4 -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 23:47:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2E88237B4EC for ; Thu, 22 Feb 2001 23:47:30 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N7iv712026; Thu, 22 Feb 2001 23:44:57 -0800 (PST) Date: Thu, 22 Feb 2001 23:44:57 -0800 From: Alfred Perlstein To: Kris Kennaway Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010222234457.D8663@fw.wintelcom.net> References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010222233800.A1394@mollari.cthul.hu>; from kris@obsecurity.org on Thu, Feb 22, 2001 at 11:38:01PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kris Kennaway [010222 23:38] wrote: > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > Hi, > > > > I'm worried about the default value of the kern.fallback_elf_brand syctl > > (= 9 -> FreeBSD). It basicly tells the kernel that binaries without any > > branding are FreeBSD binaries. Since our binaries are always branded > > (AFAICT), this seems to me as the wrong default. > > > > One problem with this is that unbranded static Linux binaries are > > executed as FreeBSD native binaries and there's a high chance of them > > rebooting the machine if run as root. > > > > I think we need to disable the fallback ELF branding when no ABI > > compatibility module is loaded. Otherwise we can set the fallback to the > > one ABI module, or when multiple are loaded, the first. In the latter > > case, the first may not be the preferred one, so we probably need to > > have a bit more tuning than simply selecting the first. > > > > Of course, we can also set the default to 3 (=Linux) under the > > assumption that the Linuxulator is the most frequently used ABI module. > > > > Thoughts? > > I've run into the unbranded Linux binary reboot before..very > annoying. I agree the default should be changed. Why does this happen? Does the exec code freak out if the default isn't present, or does some common syscall just happen to map to Linux's reboot syscall? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 22 23:50:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-188.dsl.lsan03.pacbell.net [63.207.60.188]) by hub.freebsd.org (Postfix) with ESMTP id DE3E837B4EC for ; Thu, 22 Feb 2001 23:50:36 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0EC3B66F38; Thu, 22 Feb 2001 23:50:36 -0800 (PST) Date: Thu, 22 Feb 2001 23:50:35 -0800 From: Kris Kennaway To: Alfred Perlstein Cc: Kris Kennaway , Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010222235035.A1656@mollari.cthul.hu> References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010222234457.D8663@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Feb 22, 2001 at 11:44:57PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2001 at 11:44:57PM -0800, Alfred Perlstein wrote: > * Kris Kennaway [010222 23:38] wrote: > > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > > Hi, > > >=20 > > > I'm worried about the default value of the kern.fallback_elf_brand sy= ctl > > > (=3D 9 -> FreeBSD). It basicly tells the kernel that binaries without= any > > > branding are FreeBSD binaries. Since our binaries are always branded > > > (AFAICT), this seems to me as the wrong default. > > >=20 > > > One problem with this is that unbranded static Linux binaries are > > > executed as FreeBSD native binaries and there's a high chance of them > > > rebooting the machine if run as root. > > >=20 > > > I think we need to disable the fallback ELF branding when no ABI > > > compatibility module is loaded. Otherwise we can set the fallback to = the > > > one ABI module, or when multiple are loaded, the first. In the latter > > > case, the first may not be the preferred one, so we probably need to > > > have a bit more tuning than simply selecting the first. > > >=20 > > > Of course, we can also set the default to 3 (=3DLinux) under the > > > assumption that the Linuxulator is the most frequently used ABI modul= e. > > >=20 > > > Thoughts? > >=20 > > I've run into the unbranded Linux binary reboot before..very > > annoying. I agree the default should be changed. >=20 > Why does this happen? Does the exec code freak out if the default > isn't present, or does some common syscall just happen to map to > Linux's reboot syscall? Other way around. A common Linux syscall maps to the FreeBSD reboot syscall, so if the binary is unbranded the syscalls are interpreted using the FreeBSD table, and the user is left looking very surprised. Kris --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lhZLWry0BWjoQKURApc7AKCA3+eJuOL2JaWcOjfTVXTruqCDJQCfUzdH OLsW9gV1VG2jUau5kwb9FX0= =FxRa -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 0:16:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 56DBA37B491 for ; Fri, 23 Feb 2001 00:16:16 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1N8CVW79145; Fri, 23 Feb 2001 01:12:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102230812.f1N8CVW79145@harmony.village.org> To: Kris Kennaway Subject: Re: sysctl kern.fallback_elf_brand Cc: Marcel Moolenaar , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 22 Feb 2001 23:38:01 PST." <20010222233800.A1394@mollari.cthul.hu> References: <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> Date: Fri, 23 Feb 2001 01:12:31 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010222233800.A1394@mollari.cthul.hu> Kris Kennaway writes: : I've run into the unbranded Linux binary reboot before..very : annoying. I agree the default should be changed. FreeBSD 4.0 definitely and maybe 4.1 produced binaries that were unbranded by default. The branding change happened at the same time binutils were merged from current, as far as I can tell. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 0:26:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 268B337B503 for ; Fri, 23 Feb 2001 00:26:44 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8OCl13139; Fri, 23 Feb 2001 00:24:12 -0800 (PST) Date: Fri, 23 Feb 2001 00:24:12 -0800 From: Alfred Perlstein To: Kris Kennaway Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223002412.F8663@fw.wintelcom.net> References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010222235035.A1656@mollari.cthul.hu>; from kris@obsecurity.org on Thu, Feb 22, 2001 at 11:50:35PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kris Kennaway [010222 23:50] wrote: > > > > > > I've run into the unbranded Linux binary reboot before..very > > > annoying. I agree the default should be changed. > > > > Why does this happen? Does the exec code freak out if the default > > isn't present, or does some common syscall just happen to map to > > Linux's reboot syscall? > > Other way around. A common Linux syscall maps to the FreeBSD reboot > syscall, so if the binary is unbranded the syscalls are interpreted > using the FreeBSD table, and the user is left looking very surprised. Hah, afaik reboot in linux takes magic args to prevent this sort of problem some args which happen to map to Linus's family members' birthdays or something. :) Anyhow we should refuse to run unbranded binaries as root. however as a "don't beat the user" policy it leads to: Refuse to run unbranded binaries as anyone. Which is much safer, it might be nice to have the exec code emit a message to inform the user that he may want to turn on the default exec stuff. Actually, I think it used to do this, it was far less convient to brand my binaries than to have my box reboot because I ran a linux app without branding. Now with the "default" exec stuff it becomes even easier. Basically, i don't really think the default exec stuff should be enabled by default, otherwise if we switch to linux as the default and common srv4 syscall happens to map to Linux's "eatmydisk(2)" we'll get more complaints. Turn it off and make it spew out about running brandelf or setting the sysctl, or make it just reference some emulator(4) manpage that describes the issues here. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 0:27:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-215.dsl.lsan03.pacbell.net [63.207.60.215]) by hub.freebsd.org (Postfix) with ESMTP id 4BD5137B491 for ; Fri, 23 Feb 2001 00:27:54 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E3AB366F83; Fri, 23 Feb 2001 00:27:53 -0800 (PST) Date: Fri, 23 Feb 2001 00:27:53 -0800 From: Kris Kennaway To: Alfred Perlstein Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223002753.A983@mollari.cthul.hu> References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> <20010223002412.F8663@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223002412.F8663@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Feb 23, 2001 at 12:24:12AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 23, 2001 at 12:24:12AM -0800, Alfred Perlstein wrote: > Refuse to run unbranded binaries as anyone. I like this idea..we can at least do it in -current, given the fact that older 4.x native binaries may apparently be unbranded. Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lh8JWry0BWjoQKURAsg6AJ98KTpjh4Xh54LaxjWAoiZbOfjZnwCgkpcJ P6ORwvGLb0APPp441wiE0Hc= =oYG2 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 0:34:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B70FD37B4EC for ; Fri, 23 Feb 2001 00:34:45 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1N8YTg79555; Fri, 23 Feb 2001 00:34:29 -0800 (PST) (envelope-from dillon) Date: Fri, 23 Feb 2001 00:34:29 -0800 (PST) From: Matt Dillon Message-Id: <200102230834.f1N8YTg79555@earth.backplane.com> To: Tony Finch Cc: Wes Peters , Randell Jesup , Terry Lambert , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG, Tony Finch Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> <20010223073526.F19285@hand.dotat.at> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Storing program-specific configuration data for many diverse applications in a single file is (A) a stupid idea, (B) a stupid idea, and most importantly (C) ... a stupid idea. Having config parameters all in one place does not magically make the idiot tring to manipulate them any better at his job, but it sure makes it more likely that he will take the whole system down with him when he does make a mistake! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 0:38:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2F83F37B503 for ; Fri, 23 Feb 2001 00:38:23 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8ZoR13572; Fri, 23 Feb 2001 00:35:50 -0800 (PST) Date: Fri, 23 Feb 2001 00:35:50 -0800 From: Alfred Perlstein To: Kris Kennaway Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223003550.H8663@fw.wintelcom.net> References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> <20010223002412.F8663@fw.wintelcom.net> <20010223002753.A983@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223002753.A983@mollari.cthul.hu>; from kris@obsecurity.org on Fri, Feb 23, 2001 at 12:27:53AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kris Kennaway [010223 00:27] wrote: > On Fri, Feb 23, 2001 at 12:24:12AM -0800, Alfred Perlstein wrote: > > Refuse to run unbranded binaries as anyone. > > I like this idea..we can at least do it in -current, given the fact > that older 4.x native binaries may apparently be unbranded. If you have a 4.x box, I would test this, for some reason I doubt that they have been unbranded for a long, long time unless our "file" command guesses that unbranded == freebsd. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 1: 5:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-215.dsl.lsan03.pacbell.net [63.207.60.215]) by hub.freebsd.org (Postfix) with ESMTP id 8999B37B491 for ; Fri, 23 Feb 2001 01:05:15 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2A83866C34; Fri, 23 Feb 2001 01:05:15 -0800 (PST) Date: Fri, 23 Feb 2001 01:05:15 -0800 From: Kris Kennaway To: Alexander Leidinger Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010223010514.A41551@mollari.cthul.hu> References: <20010222125552.B6517@mollari.cthul.hu> <200102222153.f1MLrsf01077@Magelan.Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102222153.f1MLrsf01077@Magelan.Leidinger.net>; from Alexander@Leidinger.net on Thu, Feb 22, 2001 at 10:53:52PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2001 at 10:53:52PM +0100, Alexander Leidinger wrote: > > Hmm, that's not what's documented in the gcc info docs. >=20 > The docs are wrong. >=20 > > `-march=3DCPU TYPE' > > Generate instructions for the machine type CPU TYPE. The choices > > for CPU TYPE are the same as for `-mcpu'. Moreover, specifying > > `-march=3DCPU TYPE' implies `-mcpu=3DCPU TYPE'. >=20 > That's not true, test it on your own (see my previous mail with my test > program) if you think the doc is right (or have a look at "man gcc" on a > system with gcc 2.95.3 (e.g. a recent -current)). Okay, I've built several binaries and libraries with -march=3Dpentiumpro and -march=3Dpentiumpro -mcpu=3Dpentiumpro, and verified with diff -b that the output in both cases is indeed identical. It looks like the docs are correct. Kris --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lifKWry0BWjoQKURAswbAJ9BOfjRi8dBXlKab72TfMeyAgLveACeLBFQ 4nUhjz/h4iridCAO7RBB8go= =Xd2V -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 4:32: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4063937B401 for ; Fri, 23 Feb 2001 04:32:01 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NCVph04142; Fri, 23 Feb 2001 04:31:51 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 04:31:49 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223043149.C2539@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102230812.f1N8CVW79145@harmony.village.org>; from imp@harmony.village.org on Fri, Feb 23, 2001 at 01:12:31AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 01:12:31AM -0700, Warner Losh wrote: > FreeBSD 4.0 definitely and maybe 4.1 produced binaries that were > unbranded by default. The branding change happened at the same time > binutils were merged from current, as far as I can tell. Uh... really? I recommend UTSL to all: src/contrib/binutils/bfd/elf.c ---------------------------- revision 1.2 date: 1998-03-01 23:15:09; author: jdp; state: Exp; lines: +5 -0 Add automatic branding of FreeBSD ELF files. ---------------------------- BTW, rev 1.3 has the RELENG_3_0_0_RELEASE tag.... -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 4:33:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id DBF4F37B491 for ; Fri, 23 Feb 2001 04:33:07 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NCQg803689; Fri, 23 Feb 2001 04:26:42 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 04:26:41 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: arch@FreeBSD.org Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223042641.B2539@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: <3A960EF8.75C3FC53@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A960EF8.75C3FC53@cup.hp.com>; from marcel@cup.hp.com on Thu, Feb 22, 2001 at 11:19:20PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > One problem with this is that unbranded static Linux binaries are > executed as FreeBSD native binaries and there's a high chance of them > rebooting the machine if run as root. I've never seen that. Everyone I've every tried just dumped core. Have you really seen running one reboot the machine? > I think we need to disable the fallback ELF branding when no ABI > compatibility module is loaded. That would be OK to me. > Of course, we can also set the default to 3 (=Linux) under the > assumption that the Linuxulator is the most frequently used ABI module. This would not be. > Thoughts? The real fix is to teach the ELF image loader to read the .note.ABI-tag section. Then statically linked Linux binaries would be correctly identified [since our branding scheme isn't accepted by anyone other than us]. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 4:34:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 5D1F737B4EC for ; Fri, 23 Feb 2001 04:34:46 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NCYeU04204; Fri, 23 Feb 2001 04:34:41 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 04:34:40 -0800 From: "David O'Brien" To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223043440.D2539@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> <20010223002412.F8663@fw.wintelcom.net> <20010223002753.A983@mollari.cthul.hu> <20010223003550.H8663@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: <20010223003550.H8663@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Feb 23, 2001 at 12:35:50AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 12:35:50AM -0800, Alfred Perlstein wrote: > unless our "file" command guesses that unbranded == freebsd. file(1) does not look at the ELF branding -- only magic numbers. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 4:44:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 98FFA37B491 for ; Fri, 23 Feb 2001 04:44:08 -0800 (PST) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 9438 invoked by uid 1000); 23 Feb 2001 12:42:12 -0000 Date: Fri, 23 Feb 2001 14:42:11 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: Marcel Moolenaar Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223144211.I1899@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, Marcel Moolenaar References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223042641.B2539@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Fri, Feb 23, 2001 at 04:26:41AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 04:26:41AM -0800, David O'Brien wrote: > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > One problem with this is that unbranded static Linux binaries are > > executed as FreeBSD native binaries and there's a high chance of them > > rebooting the machine if run as root. > > I've never seen that. Everyone I've every tried just dumped core. Have > you really seen running one reboot the machine? Yes. Go to http://www.xiph.org/paranoia/down.html, get the ``Gzipped, statically linked cdparanoia binary for Linux ELF'', unzip, do not brand, run on RELENG_4, see machine reboot. Swear under breath, wait for fsck, brand, run, watch proper operation. This is just one example. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 5: 5:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 051AD37B491 for ; Fri, 23 Feb 2001 05:05:14 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1ND5D152426; Fri, 23 Feb 2001 05:05:13 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 05:05:12 -0800 From: "David O'Brien" To: arch@FreeBSD.org, Marcel Moolenaar Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223050512.G2539@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> <20010223144211.I1899@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223144211.I1899@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Feb 23, 2001 at 02:42:11PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 02:42:11PM +0200, Peter Pentchev wrote: > Yes. Go to http://www.xiph.org/paranoia/down.html, get the ``Gzipped, > statically linked cdparanoia binary for Linux ELF'', unzip, do not brand, > run on RELENG_4, see machine reboot. I'm turning off having a default in -CURRENT as we speak, until it can be done right. I plan to MFC this for 4.3-R. Such reboots are unacceptable. I also need to sync the branding detection bits between -CURRENT and -STABLE. I would appreciate it, of no one else would touch this code for a few days. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 7: 2:12 2001 Delivered-To: freebsd-arch@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 5587E37B401 for ; Fri, 23 Feb 2001 07:02:06 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1NEwn979242; Fri, 23 Feb 2001 08:58:49 -0600 (CST) (envelope-from jlemon) Date: Fri, 23 Feb 2001 08:58:49 -0600 From: Jonathan Lemon To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223085849.I5714@prism.flugsvamp.com> References: <3A960EF8.75C3FC53@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <3A960EF8.75C3FC53@cup.hp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > I think we need to disable the fallback ELF branding when no ABI > compatibility module is loaded. Otherwise we can set the fallback to the > one ABI module, or when multiple are loaded, the first. In the latter > case, the first may not be the preferred one, so we probably need to > have a bit more tuning than simply selecting the first. I like this; I think that we should just turn off the default elf branding for now, since we've been branding our (FreeBSD) binaries since the 3.x days. How about the following patch? -- Jonathan Index: kern/imgact_elf.c =================================================================== RCS file: /ncvs/src/sys/kern/imgact_elf.c,v retrieving revision 1.89 diff -u -r1.89 imgact_elf.c --- kern/imgact_elf.c 2001/02/09 06:09:48 1.89 +++ kern/imgact_elf.c 2001/02/23 15:06:56 @@ -32,6 +32,7 @@ #include "opt_rlimit.h" #include +#include #include #include #include @@ -436,9 +437,12 @@ return error; } -static int fallback_elf_brand = ELFOSABI_FREEBSD; +/* + * non static, as it can be overridden by start_init() + */ +int fallback_elf_brand = ELFOSABI_NONE; SYSCTL_INT(_kern, OID_AUTO, fallback_elf_brand, CTLFLAG_RW, - &fallback_elf_brand, ELFOSABI_FREEBSD, + &fallback_elf_brand, ELFOSABI_NONE, "ELF brand of last resort"); static int @@ -607,10 +611,6 @@ } } } - - /* XXX - Assume FreeBSD after the branding method change. */ - if (brand_info == NULL) - brand_info = &freebsd_brand_info; if (brand_info == NULL) { uprintf("ELF binary type \"%u\" not known.\n", Index: kern/init_main.c =================================================================== RCS file: /ncvs/src/sys/kern/init_main.c,v retrieving revision 1.157 diff -u -r1.157 init_main.c --- kern/init_main.c 2001/02/21 06:39:54 1.157 +++ kern/init_main.c 2001/02/22 21:54:37 @@ -93,6 +93,7 @@ int cmask = CMASK; extern struct user *proc0paddr; +extern int fallback_elf_brand; struct vnode *rootvp; int boothowto = 0; /* initialized so that it can be patched */ @@ -479,6 +480,8 @@ strncpy(init_path, var, sizeof init_path); init_path[sizeof init_path - 1] = 0; } + if ((var = getenv("kern.fallback_elf_brand")) != NULL) + fallback_elf_brand = strtol(var, NULL, 0); for (path = init_path; *path != '\0'; path = next) { while (*path == ':') Index: sys/elf_common.h =================================================================== RCS file: /ncvs/src/sys/sys/elf_common.h,v retrieving revision 1.8 diff -u -r1.8 elf_common.h --- sys/elf_common.h 2001/01/01 21:56:57 1.8 +++ sys/elf_common.h 2001/02/23 15:08:27 @@ -100,6 +100,10 @@ #define ELFOSABI_ARM 97 /* ARM */ #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ +/* magic marker for fallback elf brand, not for e_ident[EI_OSABI] */ +#define ELFOSABI_NONE (-1) /* No OSABI defined */ + + /* e_ident */ #define IS_ELF(ehdr) ((ehdr).e_ident[EI_MAG0] == ELFMAG0 && \ (ehdr).e_ident[EI_MAG1] == ELFMAG1 && \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 8: 0:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 3495F37B67D; Fri, 23 Feb 2001 08:00:16 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1NFxpH60643; Fri, 23 Feb 2001 07:59:52 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG, marcel@cup.hp.com Subject: Re: sysctl kern.fallback_elf_brand In-Reply-To: <20010223050512.G2539@dragon.nuxi.com> References: <20010223042641.B2539@dragon.nuxi.com> <20010223144211.I1899@ringworld.oblivion.bg> <20010223050512.G2539@dragon.nuxi.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010223075951D.jkh@osd.bsdi.com> Date: Fri, 23 Feb 2001 07:59:51 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: "David O'Brien" Subject: Re: sysctl kern.fallback_elf_brand Date: Fri, 23 Feb 2001 05:05:12 -0800 > I'm turning off having a default in -CURRENT as we speak, until it can be > done right. I plan to MFC this for 4.3-R. Such reboots are > unacceptable. Erm, have you actually managed to *verify* such a reboot yet? I'd like to see this with my own eyes (or, as an acceptable substitute, yours :) before anything is done to "fix" it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:11:30 2001 Delivered-To: freebsd-arch@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 A863F37B401; Fri, 23 Feb 2001 09:11:28 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1NHAfS84987; Fri, 23 Feb 2001 11:10:41 -0600 (CST) (envelope-from jlemon) Date: Fri, 23 Feb 2001 11:10:41 -0600 From: Jonathan Lemon To: Jordan Hubbard Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG, marcel@cup.hp.com Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223111041.L5714@prism.flugsvamp.com> References: <20010223042641.B2539@dragon.nuxi.com> <20010223144211.I1899@ringworld.oblivion.bg> <20010223050512.G2539@dragon.nuxi.com> <20010223075951D.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010223075951D.jkh@osd.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 07:59:51AM -0800, Jordan Hubbard wrote: > From: "David O'Brien" > Subject: Re: sysctl kern.fallback_elf_brand > Date: Fri, 23 Feb 2001 05:05:12 -0800 > > > I'm turning off having a default in -CURRENT as we speak, until it can be > > done right. I plan to MFC this for 4.3-R. Such reboots are > > unacceptable. > > Erm, have you actually managed to *verify* such a reboot yet? I'd > like to see this with my own eyes (or, as an acceptable substitute, > yours :) before anything is done to "fix" it. The patch I posted boots and works fine over here. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:14:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 7957537B401 for ; Fri, 23 Feb 2001 09:14:19 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14WLxI-0000pc-00; Fri, 23 Feb 2001 10:24:32 -0700 Message-ID: <3A969CD0.DE9E94E1@softweyr.com> Date: Fri, 23 Feb 2001 10:24:32 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Tony Finch , Randell Jesup , Terry Lambert , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> <20010223073526.F19285@hand.dotat.at> <200102230834.f1N8YTg79555@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > Storing program-specific configuration data for many diverse applications > in a single file is (A) a stupid idea, (B) a stupid idea, and most > importantly (C) ... a stupid idea. Having config parameters all > in one place does not magically make the idiot tring to manipulate > them any better at his job, but it sure makes it more likely that he > will take the whole system down with him when he does make a mistake! Nor does stuffing a GUI on top of said configuration data, no matter where it is located, give somebody the experience to operate a complex system. Knowing how to do something does not imply knowing what to do. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:20:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5288C37B491 for ; Fri, 23 Feb 2001 09:20:35 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14WM3G-0000po-00; Fri, 23 Feb 2001 10:30:42 -0700 Message-ID: <3A969E42.BA56550@softweyr.com> Date: Fri, 23 Feb 2001 10:30:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> <20010223073526.F19285@hand.dotat.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > > Wes Peters wrote: > > > >We in the unix world have a well-founded aversion to storing configuration > >information in binary data stores that can't be accessed via ed(1) when > >the system is in single-user mode. If we wanted to stuff all the system > >configuration into such a black hole, we could've done it with DBM data- > >bases more than a decade ago, quite easily. > > You mean like spwd.db? Yes, exactly. Ask 10 unix programmers whether that was a good idea or not, and get 10 different answers, few of them positive. Yeah, yeah, yeah, so it makes uid and gid lookups faster... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:22:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id C307A37B503 for ; Fri, 23 Feb 2001 09:22:12 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14WM3y-0000pq-00; Fri, 23 Feb 2001 10:31:26 -0700 Message-ID: <3A969E6E.FC499C4E@softweyr.com> Date: Fri, 23 Feb 2001 10:31:26 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> <20010223073526.F19285@hand.dotat.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > > Wes Peters wrote: > > > >We in the unix world have a well-founded aversion to storing configuration > >information in binary data stores that can't be accessed via ed(1) when > >the system is in single-user mode. If we wanted to stuff all the system > >configuration into such a black hole, we could've done it with DBM data- > >bases more than a decade ago, quite easily. > > You mean like spwd.db? Oh, and you can at least rebuild it from an ascii file. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:23:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2181137B401 for ; Fri, 23 Feb 2001 09:23:29 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1NHNRh73749 for ; Fri, 23 Feb 2001 10:23:27 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f1NHKXN00386 for ; Fri, 23 Feb 2001 10:20:33 -0700 (MST) Message-Id: <200102231720.f1NHKXN00386@billy-club.village.org> To: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand In-reply-to: Your message of "Fri, 23 Feb 2001 04:31:49 PST." <20010223043149.C2539@dragon.nuxi.com> References: <20010223043149.C2539@dragon.nuxi.com> <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> Date: Fri, 23 Feb 2001 10:20:33 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010223043149.C2539@dragon.nuxi.com> "David O'Brien" writes: : Uh... really? I recommend UTSL to all: Yes, really. It is strip that is doing this. I have verified this on a 4.0 system that we have in house with od. It was producing different binaries than the 4.2-beta system and the only difference was the brand byte (0 vs 9). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:44:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sandman.sandgate.com (sandman.sandgate.com [38.161.139.2]) by hub.freebsd.org (Postfix) with ESMTP id DC48F37B4EC for ; Fri, 23 Feb 2001 09:44:07 -0800 (PST) (envelope-from wainer@sandgate.com) Received: from vectra (sandman.sandgate.com [38.161.139.2]) by sandman.sandgate.com (8.11.1/8.11.1) with SMTP id f1NHi2Q06417; Fri, 23 Feb 2001 12:44:03 -0500 (EST) From: "Sue Wainer" To: "Freebsd-Arch" Cc: "Jon Wells" Subject: Memory Alloation from kernel loadable driver Date: Fri, 23 Feb 2001 12:44:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C09D96.4CAC0110" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C09D96.4CAC0110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have a pci driver which is loaded using kldload. It is allocating a no. of pages by calling vm_page_alloc_contig. This convention is used by other pci drivers, though not necessarily loadable ones. On machines without much memory, or ones with more memory but having done compilations prior to kldloading, contigmalloc1 gets stuck in a continuous loop looping from the first "goto again1." There is a comment above configmalloc1 which might imply that this contiguous allocation does not work after initialization. For locked-down memory, what allocation routines should loadable drivers be calling? Is there any source of documentation of memory allocation which could be of value? Thanks. Sue Wainer wainer@sandgate.com ------=_NextPart_000_0002_01C09D96.4CAC0110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a pci driver = which is=20 loaded using kldload. It is allocating a no. of pages by calling=20 vm_page_alloc_contig.
This convention is = used by=20 other pci drivers, though not necessarily loadable = ones.
 
On machines without = much=20 memory, or ones with more memory but having done compilations prior to=20 kldloading,
contigmalloc1 gets = stuck in a=20 continuous loop looping from the first "goto again1." There is a=20 comment
above configmalloc1 = which might=20 imply that this contiguous allocation does not work after=20 initialization.
 
For locked-down = memory, what=20 allocation routines should loadable drivers be calling? Is = there any=20 source of
documentation of = memory=20 allocation which could be of value?
 
Thanks.
 
Sue = Wainer
wainer@sandgate.com <= /FONT>
 
 
------=_NextPart_000_0002_01C09D96.4CAC0110-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 9:47: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id E235E37B503 for ; Fri, 23 Feb 2001 09:47:03 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14WMTQ-0000qS-00; Fri, 23 Feb 2001 10:57:44 -0700 Message-ID: <3A96A498.770610EA@softweyr.com> Date: Fri, 23 Feb 2001 10:57:44 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "D. J. Bernstein" Cc: arch@freebsd.org Subject: Re: DJBDNS vs. BIND References: <20010221103002.3475.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "D. J. Bernstein" wrote: > > Terry is wrong when he claims that I am ``strongly opposed to offering > alternate back ends.'' There is no truth to Terry's insinuations that I > rejected Terry's SQL ideas. There is also no truth to the similar > insinuations from Jack Rusher and Wes Peters. In fact, as far as I can > tell, these people have _never_ sent any email to the dns mailing list. a) I didn't make the contact, someone else in my company did. (A domain other than softweyr.com.) b) The contact was private email, not on a mailing list. c) I said nothing about "alternate backends", but rather being able to distribute binaries of djbdns with custom modifications. You had no interest in even discussing the topic. That is your right, it's your code, so we moved on. d) You're dangerously close to calling me a liar in a public forum. That would be a really bad idea. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 10:22:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 8289237B401 for ; Fri, 23 Feb 2001 10:22:36 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 57BCC141; Fri, 23 Feb 2001 10:22:35 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA01808; Fri, 23 Feb 2001 10:22:34 -0800 (PST) Message-ID: <3A96AA6C.B2241FCA@cup.hp.com> Date: Fri, 23 Feb 2001 10:22:36 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand References: <3A960EF8.75C3FC53@cup.hp.com> <20010223085849.I5714@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > > > I think we need to disable the fallback ELF branding when no ABI > > compatibility module is loaded. Otherwise we can set the fallback to the > > one ABI module, or when multiple are loaded, the first. In the latter > > case, the first may not be the preferred one, so we probably need to > > have a bit more tuning than simply selecting the first. > > I like this; I think that we should just turn off the default elf > branding for now, since we've been branding our (FreeBSD) binaries > since the 3.x days. How about the following patch? Looks good in principle. Touch bases with obrien. He's taking the lead on this one. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 10:35:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 1B21E37B491 for ; Fri, 23 Feb 2001 10:35:23 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 51CB91D0 for ; Fri, 23 Feb 2001 10:31:46 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA02252 for ; Fri, 23 Feb 2001 10:31:45 -0800 (PST) Message-ID: <3A96AC92.F14A90B9@cup.hp.com> Date: Fri, 23 Feb 2001 10:31:46 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Re: sysctl kern.fallback_elf_brand References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > The real fix is to teach the ELF image loader to read the .note.ABI-tag > section. Then statically linked Linux binaries would be correctly > identified [since our branding scheme isn't accepted by anyone other than > us]. The use of the section seems broken to me. It's the first time I've heard of it (so I won't really know how it's used :-). AFAICT, ABI information is written in e_ident[EI_OSABI] and annotated with flags in e_flags. That should be enough for our ELF loader. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 11:31:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-57.dsl.lsan03.pacbell.net [63.207.60.57]) by hub.freebsd.org (Postfix) with ESMTP id 29C8837B401 for ; Fri, 23 Feb 2001 11:31:57 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 794C966F1F; Fri, 23 Feb 2001 11:31:56 -0800 (PST) Date: Fri, 23 Feb 2001 11:31:56 -0800 From: Kris Kennaway To: arch@FreeBSD.org Cc: Marcel Moolenaar Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223113155.B73221@mollari.cthul.hu> References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223042641.B2539@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Fri, Feb 23, 2001 at 04:26:41AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2001 at 04:26:41AM -0800, David O'Brien wrote: > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > One problem with this is that unbranded static Linux binaries are > > executed as FreeBSD native binaries and there's a high chance of them > > rebooting the machine if run as root. >=20 > I've never seen that. Everyone I've every tried just dumped core. Have > you really seen running one reboot the machine? Yes. This was under 4.2-STABLE. Unfortunately, I can't remember off the top of my head what the binary was - something extracted from a redhat 6.2 RPM, I think. Have you tried any statically linked binaries which make the correspondingly-numbered syscall (actually, I think mine triggered a halt, not a reboot, but they're both common syscall numbers)? Kris --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6lrqrWry0BWjoQKURArlKAKCmu4Z+lbhBdl8QprGhyFY2su6RYQCbB8WX Dv8MMf/jY1OWeUFAfblzCr8= =qIoq -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 11:35: 0 2001 Delivered-To: freebsd-arch@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 2092837B491 for ; Fri, 23 Feb 2001 11:34:58 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1NJYAq89801; Fri, 23 Feb 2001 13:34:10 -0600 (CST) (envelope-from jlemon) Date: Fri, 23 Feb 2001 13:34:10 -0600 From: Jonathan Lemon To: Kris Kennaway Cc: arch@FreeBSD.ORG, Marcel Moolenaar Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223133410.O5714@prism.flugsvamp.com> References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> <20010223113155.B73221@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010223113155.B73221@mollari.cthul.hu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 11:31:56AM -0800, Kris Kennaway wrote: > On Fri, Feb 23, 2001 at 04:26:41AM -0800, David O'Brien wrote: > > On Thu, Feb 22, 2001 at 11:19:20PM -0800, Marcel Moolenaar wrote: > > > One problem with this is that unbranded static Linux binaries are > > > executed as FreeBSD native binaries and there's a high chance of them > > > rebooting the machine if run as root. > > > > I've never seen that. Everyone I've every tried just dumped core. Have > > you really seen running one reboot the machine? > > Yes. This was under 4.2-STABLE. Unfortunately, I can't remember off > the top of my head what the binary was - something extracted from a > redhat 6.2 RPM, I think. Have you tried any statically linked > binaries which make the correspondingly-numbered syscall (actually, I > think mine triggered a halt, not a reboot, but they're both common > syscall numbers)? It's quite easy to reproduce. Here's why: >From sys/kern/syscalls.master: 55 STD BSD { int reboot(int opt); } >From sys/i386/linux/syscalls.master: 55 STD LINUX { int linux_fcntl(int fd, int cmd, int arg); } If you run an unbranded Linux binary, our current default assumes that it is a FreeBSD elf executable. So when the Linux binary then calls what it thinks is fcntl, it actually winds up calling reboot. *BEWM* To reproduce, just compile this program (statically) on a Linux box, and then run (as root) on a FreeBSD box: main() { fcntl(0,0,0); } -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 11:45:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id B6F8437B684 for ; Fri, 23 Feb 2001 11:45:10 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C564H; Fri, 23 Feb 2001 14:45:08 -0500 Reply-To: Randell Jesup To: arch@FreeBSD.ORG Cc: Alfred Perlstein , msinz@wgate.com (Mike Sinz), bbauman@wgate.com (Bruce Bauman) Subject: ELF and diskless boot References: <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> <20010223002412.F8663@fw.wintelcom.net> <20010223002753.A983@mollari.cthul.hu> <20010223003550.H8663@fw.wintelcom.net> <20010223043440.D2539@dragon.nuxi.com> From: Randell Jesup Date: 23 Feb 2001 14:45:59 -0500 In-Reply-To: "David O'Brien"'s message of "Fri, 23 Feb 2001 04:34:40 -0800" Message-ID: 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FYI, is there a reason that we've set up our kernel interface to top, etc to fail unless the kernel (in this case 4.x) is loaded with _debugging_ symbols? I.e. if you strip a kernel, top (and a bunch of other stuff) doesn't work because they can't find certain kernel structures. To make this worse, they also fail if you etherboot (because debug symbols aren't loaded). Is there a reason for this behavior? Perhaps some benefit we don't see? Any chance of getting this fixed? I believe this appears sometime since 3.x, i.e. after we'd already moved to ELF, but I'm not sure. (Note: I'm not the primary person investigating this; Mike is. I think he's looking at modding etherboot to work around the problem.) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 12:13:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 22BDF37B491 for ; Fri, 23 Feb 2001 12:13:33 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NKDTW68677; Fri, 23 Feb 2001 12:13:29 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 12:13:28 -0800 From: "David O'Brien" To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223121328.A68586@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <3A960EF8.75C3FC53@cup.hp.com> <20010223085849.I5714@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: <20010223085849.I5714@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Fri, Feb 23, 2001 at 08:58:49AM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 08:58:49AM -0600, Jonathan Lemon wrote: > +/* magic marker for fallback elf brand, not for e_ident[EI_OSABI] */ > +#define ELFOSABI_NONE (-1) /* No OSABI defined */ Please do not commit this (see my earlier message). My version of this uses the naked "-1". Please do not make up non-standard (ie, not defined by the ELF ABI maintainers) symbols. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 12:14:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 3BC8537B503 for ; Fri, 23 Feb 2001 12:14:54 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NKEo868693; Fri, 23 Feb 2001 12:14:50 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 12:14:49 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223121449.B68586@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010223043149.C2539@dragon.nuxi.com> <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> <20010223043149.C2539@dragon.nuxi.com> <200102231720.f1NHKXN00386@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102231720.f1NHKXN00386@billy-club.village.org>; from imp@village.org on Fri, Feb 23, 2001 at 10:20:33AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 10:20:33AM -0700, Warner Losh wrote: > In message <20010223043149.C2539@dragon.nuxi.com> "David O'Brien" writes: > : Uh... really? I recommend UTSL to all: > > Yes, really. It is strip that is doing this. I have verified this on > a 4.0 system that we have in house with od. It was producing > different binaries than the 4.2-beta system and the only difference > was the brand byte (0 vs 9). That is because the branding method changed. Again, go look at either the code of sys/kern/imgact_elf.c or contrib/binutils/bfd/elf.c. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 12:22: 9 2001 Delivered-To: freebsd-arch@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 131B537B401; Fri, 23 Feb 2001 12:22:07 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1NKLK791480; Fri, 23 Feb 2001 14:21:20 -0600 (CST) (envelope-from jlemon) Date: Fri, 23 Feb 2001 14:21:20 -0600 From: Jonathan Lemon To: "David O'Brien" Cc: Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223142120.Q5714@prism.flugsvamp.com> References: <3A960EF8.75C3FC53@cup.hp.com> <20010223085849.I5714@prism.flugsvamp.com> <20010223121328.A68586@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010223121328.A68586@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 12:13:28PM -0800, David O'Brien wrote: > On Fri, Feb 23, 2001 at 08:58:49AM -0600, Jonathan Lemon wrote: > > +/* magic marker for fallback elf brand, not for e_ident[EI_OSABI] */ > > +#define ELFOSABI_NONE (-1) /* No OSABI defined */ > > Please do not commit this (see my earlier message). > > My version of this uses the naked "-1". Please do not make up > non-standard (ie, not defined by the ELF ABI maintainers) symbols. Yes, I thought about doing that as well, but thought it might be clearer to have the '-1' documented somewhere, especially since it is visible to the user via a sysctl. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 12:26:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E7BE937B4EC for ; Fri, 23 Feb 2001 12:26:36 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1NKQaW82988 for ; Fri, 23 Feb 2001 13:26:36 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102232026.f1NKQaW82988@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand In-reply-to: Your message of "Fri, 23 Feb 2001 12:14:49 PST." <20010223121449.B68586@dragon.nuxi.com> References: <20010223121449.B68586@dragon.nuxi.com> <20010223043149.C2539@dragon.nuxi.com> <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> <20010223043149.C2539@dragon.nuxi.com> <200102231720.f1NHKXN00386@billy-club.village.org> Date: Fri, 23 Feb 2001 13:26:36 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010223121449.B68586@dragon.nuxi.com> "David O'Brien" writes: : On Fri, Feb 23, 2001 at 10:20:33AM -0700, Warner Losh wrote: : > In message <20010223043149.C2539@dragon.nuxi.com> "David O'Brien" writes: : > : Uh... really? I recommend UTSL to all: : > : > Yes, really. It is strip that is doing this. I have verified this on : > a 4.0 system that we have in house with od. It was producing : > different binaries than the 4.2-beta system and the only difference : > was the brand byte (0 vs 9). : : That is because the branding method changed. Again, go look at either : the code of sys/kern/imgact_elf.c or contrib/binutils/bfd/elf.c. Translated into a useful answer: The old brand byte of 0 won't cause problems because the old branding is different than the linux binaries causing problems. You don't have to be so curt with me about this, you know. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 12:34:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0B06B37B65D for ; Fri, 23 Feb 2001 12:34:16 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1NKUEW83024; Fri, 23 Feb 2001 13:30:14 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102232030.f1NKUEW83024@harmony.village.org> To: Kris Kennaway Subject: Re: sysctl kern.fallback_elf_brand Cc: Alfred Perlstein , Marcel Moolenaar , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 23 Feb 2001 00:27:53 PST." <20010223002753.A983@mollari.cthul.hu> References: <20010223002753.A983@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <20010222234457.D8663@fw.wintelcom.net> <20010222235035.A1656@mollari.cthul.hu> <20010223002412.F8663@fw.wintelcom.net> Date: Fri, 23 Feb 2001 13:30:14 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010223002753.A983@mollari.cthul.hu> Kris Kennaway writes: : I like this idea..we can at least do it in -current, given the fact : that older 4.x native binaries may apparently be unbranded. As david attemtped to cryptically point out, they are branded, but with the "old style" brands which the kernel properly recognizes as FreeBSD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 14:33:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 02FE237B401; Fri, 23 Feb 2001 14:33:37 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1NMUxl43655; Fri, 23 Feb 2001 14:30:59 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <20010223142120.Q5714@prism.flugsvamp.com> Date: Fri, 23 Feb 2001 14:33:15 -0800 (PST) From: John Baldwin To: Jonathan Lemon Subject: Re: sysctl kern.fallback_elf_brand Cc: arch@FreeBSD.org, "David O'Brien" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-01 Jonathan Lemon wrote: > On Fri, Feb 23, 2001 at 12:13:28PM -0800, David O'Brien wrote: >> On Fri, Feb 23, 2001 at 08:58:49AM -0600, Jonathan Lemon wrote: >> > +/* magic marker for fallback elf brand, not for e_ident[EI_OSABI] */ >> > +#define ELFOSABI_NONE (-1) /* No OSABI defined */ >> >> Please do not commit this (see my earlier message). >> >> My version of this uses the naked "-1". Please do not make up >> non-standard (ie, not defined by the ELF ABI maintainers) symbols. > > Yes, I thought about doing that as well, but thought it might be > clearer to have the '-1' documented somewhere, especially since > it is visible to the user via a sysctl. Then write a SYSCTL_PROC that uses strings to interface to the user rather than numbers... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 14:36: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4481837B401 for ; Fri, 23 Feb 2001 14:36:02 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1NMV0l43659; Fri, 23 Feb 2001 14:31:00 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <3A96AC92.F14A90B9@cup.hp.com> Date: Fri, 23 Feb 2001 14:33:16 -0800 (PST) From: John Baldwin To: Marcel Moolenaar Subject: Re: sysctl kern.fallback_elf_brand Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-01 Marcel Moolenaar wrote: > David O'Brien wrote: >> >> The real fix is to teach the ELF image loader to read the .note.ABI-tag >> section. Then statically linked Linux binaries would be correctly >> identified [since our branding scheme isn't accepted by anyone other than >> us]. > > The use of the section seems broken to me. It's the first time I've > heard of it (so I won't really know how it's used :-). AFAICT, ABI > information is written in e_ident[EI_OSABI] and annotated with flags in > e_flags. That should be enough for our ELF loader. I talked with O`Brien about this today. Many other people view this field as being used when you _extend_ the ELF specification itself. Not as a mechanism for running a plain ELF binary and marking which set of system calls, etc. it assumes. The other method is apparently already used by Linux, BSD/OS, {Net,Open}BSD, etc. I.e., by the rest of the world. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 15:42:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E3F8A37B491 for ; Fri, 23 Feb 2001 15:42:51 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA07893; Fri, 23 Feb 2001 16:37:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAIxaavp; Fri Feb 23 16:37:26 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA01378; Fri, 23 Feb 2001 16:42:30 -0700 (MST) From: Terry Lambert Message-Id: <200102232342.QAA01378@usr05.primenet.com> Subject: Configuration management To: wes@softweyr.com (Wes Peters) Date: Fri, 23 Feb 2001 23:42:30 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <3A969CD0.DE9E94E1@softweyr.com> from "Wes Peters" at Feb 23, 2001 10:24:32 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Storing program-specific configuration data for many diverse applications > > in a single file is (A) a stupid idea, (B) a stupid idea, and most > > importantly (C) ... a stupid idea. Having config parameters all > > in one place does not magically make the idiot tring to manipulate > > them any better at his job, but it sure makes it more likely that he > > will take the whole system down with him when he does make a mistake! > > > Nor does stuffing a GUI on top of said configuration data, no matter where > it is located, give somebody the experience to operate a complex system. > Knowing how to do something does not imply knowing what to do. > The lack of a configuration data API, and a common configuration file layout syntax has been a problem with UNIX since day 1. When you learn how to configure one program, the knowledge is not transferrable over to another program; you must relearn it for each program, which make UNIX unnecessarily dense, with an unnecessarily high learning curve, but with no benefit of having achieved a greater altitude for having climbed N of these curves, as opposed to N-1 of these curves. Further, the lack of a single data channel to which the API talks means that proxy configuration of a number of machines can't be done over a network. Nor can one multiplex the proxy stream to change machine independent data on a large number of machines simultaneously. Neither can computable machine specific data be handled this way (e.g. renumbering a network). Additionally, when a GUI is provided, even if that GUI is not a direct representation of the configuration hierarchy, or it abstracts the complexity to a level usable by an end user at any given level of capability (as the MVC -- Model, View, Controller -- paradigm favored by Activity Theory and HCI -- Human Computer Interaction -- dictates should be done), it is _gratuitously_ difficult to supply, due to the exhausting number of back end interfaces which have to be written. So _you_ don't want a GUI: BFD. So _you_ don't want to do cluster configuration: BFD. So _you_ don't want to do role based configuration of subsets of a cluster spread over multiple colocation facilities: BFD. The point is that just because some people don't see a need for something doesn't make it useless. Ask the next Amish person you meet whether or not there should be cars; then tell me if you're prepared to give up your car, if you have one. Even if we stick with "flat text files", and we continue to edit them by hand, instead of using a method with subschema inforcement which makes non-sensical configurations impossible (per Jordan's XML example), the idea that it should be _possible_ to easily and efficiently machine parse and write these files using a single API, which can be proxied over a network through a single data channel, is a valid one. 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-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 15:48:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 58F7837B401 for ; Fri, 23 Feb 2001 15:48:38 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA09757; Fri, 23 Feb 2001 16:43:19 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA0LaObt; Fri Feb 23 16:43:11 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA01498; Fri, 23 Feb 2001 16:48:16 -0700 (MST) From: Terry Lambert Message-Id: <200102232348.QAA01498@usr05.primenet.com> Subject: Re: Memory Alloation from kernel loadable driver To: wainer@sandgate.com (Sue Wainer) Date: Fri, 23 Feb 2001 23:48:16 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (Freebsd-Arch), jon@bigbang.com.au (Jon Wells) In-Reply-To: from "Sue Wainer" at Feb 23, 2001 12:44:02 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have a pci driver which is loaded using kldload. It is allocating a no. of > pages by calling vm_page_alloc_contig. > This convention is used by other pci drivers, though not necessarily > loadable ones. > > On machines without much memory, or ones with more memory but having done > compilations prior to kldloading, > contigmalloc1 gets stuck in a continuous loop looping from the first "goto > again1." There is a comment > above configmalloc1 which might imply that this contiguous allocation does > not work after initialization. > > For locked-down memory, what allocation routines should loadable drivers be > calling? Is there any source of > documentation of memory allocation which could be of value? The classic answer to this is to load you driver as part of the boot process, perhaps even having it in the list of things loaded by the boot loader, to ensure that sufficient contiguous memory is available for it. Theoretically, it's possible to defragment the kernel page map in order to free up contiguous physical memory, and it is not in practice too hard, so long as your defragmenter does not touch the pages it references. The task is a little more complex for things like shared memory objects, since you have to deal with the process page maps as well. It's also somewhat complicated by the agressive caching of clean pages. The easiest thing to do is to copy the pages around, and allocate the original pages to the contiguous zone being created atomically, rather than freeing the pages back to the system. 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-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 15:53:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id BB70237B491 for ; Fri, 23 Feb 2001 15:53:35 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id QAA59200; Fri, 23 Feb 2001 16:53:05 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdjFMlMa; Fri Feb 23 16:53:02 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA01672; Fri, 23 Feb 2001 16:53:25 -0700 (MST) From: Terry Lambert Message-Id: <200102232353.QAA01672@usr05.primenet.com> Subject: Re: ELF and diskless boot To: rjesup@wgate.com Date: Fri, 23 Feb 2001 23:53:25 +0000 (GMT) Cc: arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein), msinz@wgate.com (Mike Sinz), bbauman@wgate.com (Bruce Bauman) In-Reply-To: from "Randell Jesup" at Feb 23, 2001 02:45:59 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > FYI, is there a reason that we've set up our kernel interface to top, etc > to fail unless the kernel (in this case 4.x) is loaded with _debugging_ > symbols? I.e. if you strip a kernel, top (and a bunch of other stuff) > doesn't work because they can't find certain kernel structures. To make > this worse, they also fail if you etherboot (because debug symbols aren't > loaded). Strip is supposed to be able to strip the debugging information without stripping non-debugging information. This is normally how you run a source level debugger on the kernel from another machine (or using VMware, julians pseudo-console-serial driver, and another window on the same machine): you boot the stripped kernel, and GDB with the unstripped kernel. Sounds like you are either giving the wrong arguments to strip, or it's not working on your platform (e.g. alpha). 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-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 15:55:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 5F84E37B491 for ; Fri, 23 Feb 2001 15:55:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id QAA21216; Fri, 23 Feb 2001 16:55:29 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpd0BA9Ua; Fri Feb 23 16:55:21 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA01722; Fri, 23 Feb 2001 16:55:44 -0700 (MST) From: Terry Lambert Message-Id: <200102232355.QAA01722@usr05.primenet.com> Subject: Re: sysctl kern.fallback_elf_brand To: imp@harmony.village.org (Warner Losh) Date: Fri, 23 Feb 2001 23:55:44 +0000 (GMT) Cc: kris@obsecurity.org (Kris Kennaway), bright@wintelcom.net (Alfred Perlstein), marcel@cup.hp.com (Marcel Moolenaar), arch@FreeBSD.ORG In-Reply-To: <200102232030.f1NKUEW83024@harmony.village.org> from "Warner Losh" at Feb 23, 2001 01:30:14 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : I like this idea..we can at least do it in -current, given the fact > : that older 4.x native binaries may apparently be unbranded. > > As david attemtped to cryptically point out, they are branded, but > with the "old style" brands which the kernel properly recognizes as > FreeBSD. I guess someone has told the USL derive ELF using UNIX vendors about this, so they can retroactively update all their binaries from all the third party vendors in the world? 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-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 15:57:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id E498737B491 for ; Fri, 23 Feb 2001 15:57:33 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1NNvWC73255; Fri, 23 Feb 2001 15:57:32 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 15:57:31 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223155731.A72750@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010223042641.B2539@dragon.nuxi.com> <20010223144211.I1899@ringworld.oblivion.bg> <20010223050512.G2539@dragon.nuxi.com> <20010223075951D.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010223075951D.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Feb 23, 2001 at 07:59:51AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 07:59:51AM -0800, Jordan Hubbard wrote: > > I'm turning off having a default in -CURRENT as we speak, until it can be > > done right. I plan to MFC this for 4.3-R. Such reboots are > > unacceptable. > > Erm, have you actually managed to *verify* such a reboot yet? I'd > like to see this with my own eyes (or, as an acceptable substitute, > yours :) before anything is done to "fix" it. I've actually never been happy enough with the heuristics used and fragility of the code in picking an ABI to run a binary under to trust it to having a fall-back default. So this seemed like a good time to change things since the Security Team is backing the change. I personally don't think there should be a default fall-back. If we added code to search for the .note.ABI-tag a lot more binaries would be properly recognized. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16: 0:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id C5B1137B491; Fri, 23 Feb 2001 16:00:12 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id EC89646D; Fri, 23 Feb 2001 16:00:04 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA16952; Fri, 23 Feb 2001 16:00:04 -0800 (PST) Message-ID: <3A96F984.7233C733@cup.hp.com> Date: Fri, 23 Feb 2001 16:00:04 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > > The use of the section seems broken to me. It's the first time I've > > heard of it (so I won't really know how it's used :-). AFAICT, ABI > > information is written in e_ident[EI_OSABI] and annotated with flags in > > e_flags. That should be enough for our ELF loader. > > I talked with O`Brien about this today. Many other people view this field as > being used when you _extend_ the ELF specification itself. Not as a mechanism > for running a plain ELF binary and marking which set of system calls, etc. it > assumes. I'm not sure that's a valid view, because ELF was originally defined as *part* of an ABI. Consequently, it does not *define* an ABI. With the adoption of ELF by different ABI providers, the lack of ABI information in ELF was apparent. It seems to me that the addition of EI_OSABI is to address this shortcoming in the ELF specification and further allows ABI specific flags to be used in the ELF file. The ELF modification/extension architects which fields and which bits in fields you can use for OS or machine specific information. Do any of you have pointers to ELF specifications that document the ABI section. The ELF specifications I use can be found: http://developer.intel.com/vtune/tis.htm http://developer.intel.com/design/ia-64/downloads/245370.htm -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:16:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 02D2137B401; Fri, 23 Feb 2001 16:16:41 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id RAA09136; Fri, 23 Feb 2001 17:16:14 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpddTBQaa; Fri Feb 23 17:16:11 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA02409; Fri, 23 Feb 2001 17:16:35 -0700 (MST) From: Terry Lambert Message-Id: <200102240016.RAA02409@usr05.primenet.com> Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] To: marcel@cup.hp.com (Marcel Moolenaar) Date: Sat, 24 Feb 2001 00:16:35 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: <3A96F984.7233C733@cup.hp.com> from "Marcel Moolenaar" at Feb 23, 2001 04:00:04 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure that's a valid view, because ELF was originally defined as > *part* of an ABI. Consequently, it does not *define* an ABI. With the > adoption of ELF by different ABI providers, the lack of ABI information > in ELF was apparent. It seems to me that the addition of EI_OSABI is to > address this shortcoming in the ELF specification and further allows ABI > specific flags to be used in the ELF file. The ELF > modification/extension architects which fields and which bits in fields > you can use for OS or machine specific information. ELF is an object file format. Adding sections is permitted, even under a strict interpretation, but the sections you add are not part of the ELF standard. Technically, ELF would let you have binaries for multiple processor platforms and architectures in the same file, as long as those platforms could agree on who owns what section, by way of some common metadata. There was a NeXTStep ELF that never panned out that could do bother 68k and x86 in the same binary. I can't provide sources on this, sorry. > Do any of you have pointers to ELF specifications that document the ABI > section. > > The ELF specifications I use can be found: > > http://developer.intel.com/vtune/tis.htm > http://developer.intel.com/design/ia-64/downloads/245370.htm The Microsoft Portable Executable format is ELF; it defines many additional section attributes, including paging control, initialize-and-discard (driver probe/attach, etc.), and so on. See also: http://msdn.microsoft.com/library/specs/msdn_pecoff.htm Note that this covers both PE files and COFF files, so it's minorly confusing. There used to be an NT 3.x PE format document that covered only the ELF stuff, but I'm unable to locate 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-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:17:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id A049537B4EC for ; Fri, 23 Feb 2001 16:17:39 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f1O0Ck608121 for ; Fri, 23 Feb 2001 16:12:46 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: sysctl kern.fallback_elf_brand Date: Fri, 23 Feb 2001 16:19:16 -0800 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.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Yes, I thought about doing that as well, but thought it might be > > clearer to have the '-1' documented somewhere, especially since > > it is visible to the user via a sysctl. > > Then write a SYSCTL_PROC that uses strings to interface to the user > rather than > numbers... Speaking of sysctl without a defined numeric code ... #include #include #include #include #include #include #include #include #include I had to include all that kernel junk (grep, parse error messages, repeat - if there are dependencies, why can't *_var.h include them for me?) just to get a few codes for some net.inet.* sysctls. I was going to come up with a patch to properly #ifdef _KERNEL the offending nonsense, but then I discovered by searching kernel source that a few of the sysctls I wanted could only be referenced by strings ... man sysctl(3) does not mention any of this. sysctl should be prominently marked as deprecated in favor of sysctlbyname, since many of the sysctl-code-containing include files don't aren't vetted properly for inclusion by user code. I wanted to use the numeric codes to benefit from compile-time checking. I was not concerned with "optimization" of a one-off call. Overall, I was isappointed with my wild-goose-chase encouraged by the misleading documentation for sysctl. -Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:17:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id EC31A37B4EC for ; Fri, 23 Feb 2001 16:17:55 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1O0BXF73698; Fri, 23 Feb 2001 16:11:33 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 16:11:33 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: arch@FreeBSD.org Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223161133.B72750@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <3A960EF8.75C3FC53@cup.hp.com> <20010223042641.B2539@dragon.nuxi.com> <3A96AC92.F14A90B9@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A96AC92.F14A90B9@cup.hp.com>; from marcel@cup.hp.com on Fri, Feb 23, 2001 at 10:31:46AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 10:31:46AM -0800, Marcel Moolenaar wrote: > > The real fix is to teach the ELF image loader to read the .note.ABI-tag > > section. Then statically linked Linux binaries would be correctly > > identified [since our branding scheme isn't accepted by anyone other than > > us]. > > The use of the section seems broken to me. It's the first time I've > heard of it (so I won't really know how it's used :-). AFAICT, ABI > information is written in e_ident[EI_OSABI] and annotated with flags in > e_flags. That should be enough for our ELF loader. Please, PLEASE, P-L-E-A-S-E don't go there. TRUST me on this one. The topic of ELF branding was the nastiest thread in a GNU toolchain mailing list I've ever been involved in. See http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox You may have your position due to it actually being specified [at one time] in the IA-64 psABI(http://developer.intel.com/design/ia-64/downloads/245370.htm). The spec is wrong, the committee changed this many months ago, yet never bothered to fix the doc for the rest or the world for a long time. So unless you are one of the {\extream_sarcasm Blessed}, you wouldn't know this. Go pester Cary Coutant of HP (in Cupertino even) about it. Note that the ELF *ABI people will not address our needs of dealing with foreign static binaries: For statically-bound programs, I'm afraid we don't have a clear solution. We took the general approach that such programs are not ABI-conforming in the first place -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX P.S. We "brand" our binaries this way, so does BSD/OS, NetBSD, and Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:21: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4632537B491 for ; Fri, 23 Feb 2001 16:21:07 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1O0G5h73827; Fri, 23 Feb 2001 16:16:05 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 16:16:04 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] Message-ID: <20010223161604.C72750@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3A96F984.7233C733@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A96F984.7233C733@cup.hp.com>; from marcel@cup.hp.com on Fri, Feb 23, 2001 at 04:00:04PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 04:00:04PM -0800, Marcel Moolenaar wrote: > Do any of you have pointers to ELF specifications that document the ABI > section. Of course not! The {\extreme_sarcasm Blessed} ones want to hold all the knowledge on this so we have to beg that they take pity on us and teach us the One True Way. (it's amusing many of them are GPV adovcates who preach "Freedom of Knowledge) (see http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox) It is up to you to remove the {\extreme_sarcasm Blessed} distinction since you have better contacts with those of power on the IA-64 psABI committee than I do. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX P.S. I'm trying to get invited to these meetings, but my contacts haven't been able to hook me up yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 2AFCB37B401 for ; Fri, 23 Feb 2001 16:23:46 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1O0NgS73994; Fri, 23 Feb 2001 16:23:42 -0800 (PST) (envelope-from obrien) Date: Fri, 23 Feb 2001 16:23:42 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand Message-ID: <20010223162342.E72750@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010223121449.B68586@dragon.nuxi.com> <20010223043149.C2539@dragon.nuxi.com> <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> <20010223043149.C2539@dragon.nuxi.com> <200102231720.f1NHKXN00386@billy-club.village.org> <20010223121449.B68586@dragon.nuxi.com> <200102232026.f1NKQaW82988@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102232026.f1NKQaW82988@harmony.village.org>; from imp@harmony.village.org on Fri, Feb 23, 2001 at 01:26:36PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001 at 01:26:36PM -0700, Warner Losh wrote: > In message <20010223121449.B68586@dragon.nuxi.com> "David O'Brien" writes: > : > Yes, really. It is strip that is doing this. I have verified this on > : > a 4.0 system that we have in house with od. It was producing > : > different binaries than the 4.2-beta system and the only difference > : > was the brand byte (0 vs 9). > : > : That is because the branding method changed. Again, go look at either > : the code of sys/kern/imgact_elf.c or contrib/binutils/bfd/elf.c. > > Translated into a useful answer: > The old brand byte of 0 won't cause problems because the old > branding is different than the linux binaries causing > problems. I can't even understand that translation. The old way of branding was to write "FreeBSD" into an unused (but reserved) area of the ELF header. An e_ident value of "0" means "NONE specified". Now it means "SysV". Currently we brand ELF binaries in three ways: * writing the string "FreeBSD" into the header * setting e_ident to "ELFOSABI_FREEBSD" (which could theoretically, potentially create problems with "generic" ELF processing tools * append a ".note.ABI-tag" ELF section that follows the format used by NetBSD (http://www.netbsd.org/Documentation/kernel/elf-notes.html) The difference you noted was that old 4.0 binaries did not set the e_ident ELF header field to anything. If I removed (1) above as I should, you would also have seen that difference of course. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:31:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 90B8B37B4EC for ; Fri, 23 Feb 2001 16:31:32 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1O0VRW84469 for ; Fri, 23 Feb 2001 17:31:32 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102240031.f1O0VRW84469@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: sysctl kern.fallback_elf_brand In-reply-to: Your message of "Fri, 23 Feb 2001 16:23:42 PST." <20010223162342.E72750@dragon.nuxi.com> References: <20010223162342.E72750@dragon.nuxi.com> <20010223121449.B68586@dragon.nuxi.com> <20010223043149.C2539@dragon.nuxi.com> <20010222233800.A1394@mollari.cthul.hu> <3A960EF8.75C3FC53@cup.hp.com> <20010222233800.A1394@mollari.cthul.hu> <200102230812.f1N8CVW79145@harmony.village.org> <20010223043149.C2539@dragon.nuxi.com> <200102231720.f1NHKXN00386@billy-club.village.org> <20010223121449.B68586@dragon.nuxi.com> <200102232026.f1NKQaW82988@harmony.village.org> Date: Fri, 23 Feb 2001 17:31:27 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010223162342.E72750@dragon.nuxi.com> "David O'Brien" writes: : > Translated into a useful answer: : > The old brand byte of 0 won't cause problems because the old : > branding is different than the linux binaries causing : > problems. : : I can't even understand that translation. OK, the following is better: "The old way of branding the binaries write FreeBSD into an unused part of the header and set e_ident to 0. 4.0 did this. However, that won't cause problems because the problementic Linux binaries have e_ident set to 0, but no FreeBSD in that unused part of the header. This menas that it is safe to MFC." : The difference you noted was that old 4.0 binaries did not set the : e_ident ELF header field to anything. If I removed (1) above as I : should, you would also have seen that difference of course. Right. I was confused. It happens sometimes. I litterally had found the difference earlier in the day and jumped to the wrong conclusion. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 16:56:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id A143537B401; Fri, 23 Feb 2001 16:56:24 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f1O0T3t10894; Fri, 23 Feb 2001 16:29:03 -0800 Date: Fri, 23 Feb 2001 16:29:03 -0800 From: Brooks Davis To: Terry Lambert Cc: Marcel Moolenaar , John Baldwin , arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] Message-ID: <20010223162903.A7882@Odin.AC.HMC.Edu> References: <3A96F984.7233C733@cup.hp.com> <200102240016.RAA02409@usr05.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102240016.RAA02409@usr05.primenet.com>; from tlambert@primenet.com on Sat, Feb 24, 2001 at 12:16:35AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 24, 2001 at 12:16:35AM +0000, Terry Lambert wrote: > Technically, ELF would let you have binaries for multiple > processor platforms and architectures in the same file, as > long as those platforms could agree on who owns what section, > by way of some common metadata. There was a NeXTStep ELF > that never panned out that could do bother 68k and x86 in > the same binary. I can't provide sources on this, sorry. Darwin uses this or similar support. The people from Apple has stated that they want fat binary support in openpackages. It's also been suggested that this could save substantial space on the NetBSD package CDs and could allow a single /usr/local for an entire cluster of machines with different architectures without resorting to mounting hacks or run scripts. As FreeBSD continues to grow new architecture ports this might be useful here as well. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6lwBOXY6L6fI4GtQRAvLIAJ9d2O+vAE1c/Fi/sWnGI6YLXGiOxQCfUUc1 zNPkZWFtDR4UdtPEkh+XUsc= =9LEy -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 18:42:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0DC5437B491 for ; Fri, 23 Feb 2001 18:42:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA24829; Sat, 24 Feb 2001 13:42:10 +1100 Date: Sat, 24 Feb 2001 13:33:14 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kris Kennaway Cc: Alexander Leidinger , arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk In-Reply-To: <20010223010514.A41551@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Feb 2001, Kris Kennaway wrote: > On Thu, Feb 22, 2001 at 10:53:52PM +0100, Alexander Leidinger wrote: > > > Hmm, that's not what's documented in the gcc info docs. > > > > The docs are wrong. > > > > > `-march=CPU TYPE' > > > Generate instructions for the machine type CPU TYPE. The choices > > > for CPU TYPE are the same as for `-mcpu'. Moreover, specifying > > > `-march=CPU TYPE' implies `-mcpu=CPU TYPE'. > > > > That's not true, test it on your own (see my previous mail with my test > > program) if you think the doc is right (or have a look at "man gcc" on a > > system with gcc 2.95.3 (e.g. a recent -current)). No, the docs are correct here. Don't look at "man gcc". It is not maintained except by non-FSF volunteers (see the WARNING section on the first page of it). In practice, this means that it hasn't changed significantly since rev.1.1.1.1 in 1994. > Okay, I've built several binaries and libraries with -march=pentiumpro > and -march=pentiumpro -mcpu=pentiumpro, and verified with diff -b that > the output in both cases is indeed identical. It looks like the docs > are correct. ITYM "incorrect". This just shows that your tests didn't test the small areas where -march makes a difference (other than implying -mcpu). Examination of gcc.295/config/i386/i386.{md,h} shows that it it only mainly (only?) affects areas related to the i686 fcmov instruction. The following program uses these areas, so compiling it with -march=pentiumpro and -mcpu=pentiumpro gives different results: --- double d; int i; int main(void) { return (d == i); } --- Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 23 20: 5:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id D2B7837B4EC for ; Fri, 23 Feb 2001 20:05:44 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA22728; Fri, 23 Feb 2001 20:53:07 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA4vaqxS; Fri Feb 23 20:53:02 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA07092; Fri, 23 Feb 2001 20:58:06 -0700 (MST) From: Terry Lambert Message-Id: <200102240358.UAA07092@usr05.primenet.com> Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] To: arch@FreeBSD.ORG Date: Sat, 24 Feb 2001 03:58:06 +0000 (GMT) Cc: marcel@cup.hp.com (Marcel Moolenaar) In-Reply-To: <20010223161604.C72750@dragon.nuxi.com> from "David O'Brien" at Feb 23, 2001 04:16:04 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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Do any of you have pointers to ELF specifications that document the ABI > > section. > > Of course not! The {\extreme_sarcasm Blessed} ones want to hold all the > knowledge on this so we have to beg that they take pity on us and teach > us the One True Way. (it's amusing many of them are GPV adovcates who > preach "Freedom of Knowledge) > > (see http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox) > > It is up to you to remove the {\extreme_sarcasm Blessed} distinction > since you have better contacts with those of power on the IA-64 psABI > committee than I do. One of the messages in your archives says: > http://developer.intel.com/design/IA-64/Downloads/24537002.pdf > > Note that the second paragraph in section 1.1 of that specification > includes the following: > > This document is the result of consensus among operating system > vendors intending to provide UNIX and UNIX workalike operating > systems on the IA-64 architecture. The vendors participating in > this effort include Intel, Sun Microsystems, SCO, IBM, SGI, > Cygnus Solutions, VA Linux Systems, HP, and Compaq. It's interesting that you didn't take them to task over the suggestion that statically linked binaries were, by definition, non conforming. I have to say that, as a practical matter, the idea that a compliant program could run on any compliant platform is a good one, but the idea that programs will not be statically linked by vendors seeking to comply with library license redistribution clauses is absurd. I know that SVR4 has, for a long time, mapped ld.so into the image space of binaries in the loader in the kernel. It seems to me that ABI compatability is a hard row to hoe in light of that mapping. I also think that libc mapping too heavily assumes what do and do not constitute symbols externalized by libc, particularly in light of pthreads and the "errno" definitio, as permitted by POSIX (not to mention the system error strings, environ, and related garbage of a similar nature). It seems to me that what they are definiing is Pascal: something that you can build programs which run, but for which there are no defined file I/O mechanisms within the scope of that standard (in this instance, no system calls). I think you are pissing in the wind with regard to H.J. Lu and others in the Linux camp: the want the Linux system call interface to be a pig more equal than others, and it seems to me that it is intentional that they are squatting on "0" to try and hijack the system call interface. Good luck in getting to the committee meetings; my suggestion would be to work through HP, Intel, Sun, Compaq, or IBM, as they are the most "disinterested" of the parties involved. Clearly, several of them are in the camp of having "misunderstood" about the "intent" of "operating system and", and in most dire need of it staying in the standard. HP won't be able to offer a PA-RISC targetd binary that also runs on an IA-64 without it, for example (NB: this may be in the interests of the "IA-64 yes, PA-RISC no" camp in HP, but there have got to be proponents of both sides there somewhere). 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-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 5:24: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id CC3A437B4EC for ; Sat, 24 Feb 2001 05:23:49 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1ODO6L24033; Sat, 24 Feb 2001 14:24:06 +0100 (CET) (envelope-from adrian) Date: Sat, 24 Feb 2001 14:24:06 +0100 From: Adrian Chadd To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Configuration management Message-ID: <20010224142406.A23979@roaming.cacheboy.net> References: <3A969CD0.DE9E94E1@softweyr.com> <200102232342.QAA01378@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102232342.QAA01378@usr05.primenet.com>; from tlambert@primenet.com on Fri, Feb 23, 2001 at 11:42:30PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 23, 2001, Terry Lambert wrote: > Even if we stick with "flat text files", and we continue to > edit them by hand, instead of using a method with subschema > inforcement which makes non-sensical configurations impossible > (per Jordan's XML example), the idea that it should be _possible_ > to easily and efficiently machine parse and write these files > using a single API, which can be proxied over a network through > a single data channel, is a valid one. Wow. I'm agreeing with Terry here. I once worked for a large ISP. They had lots and lots of boxes, and they were able to do stuff like install a custom (in-house modified) installation of Redhat (or FreeBSD if they really wanted to) which, when placed on the network, automagically picked up its "role" and configured itself. It then could continue this "role" with periodic configuration updates. How they did it was evil. They had an SQL database(s) with the entire network configuration which they then wrote scripts which would query the database with the machine hostname, pull down a configuration/to-do-list (eg create account "foo", delete account "blah", etc..) and then apply these changes locally. Each application required a seperate set of scripts to maintain. I don't think they had a cute way of updating the RPMs on the machines besides manually doing it, but I'm sure they've solved that one by now. The point is, in order to go from stand-alone UNIX machines to lots-o-machines and have them manageable and flexible required a hell of _a lot_ of work. Just a case study for y'all, Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 7:55:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 30B9A37B4EC for ; Sat, 24 Feb 2001 07:55:40 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 1525 invoked by uid 666); 24 Feb 2001 16:07:52 -0000 Received: from i079-246.nv.iinet.net.au (HELO elischer.org) (203.59.79.246) by mail.m.iinet.net.au with SMTP; 24 Feb 2001 16:07:52 -0000 Message-ID: <3A97D958.6AFC713@elischer.org> Date: Sat, 24 Feb 2001 07:55:04 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Adrian Chadd Cc: Terry Lambert , arch@freebsd.org, archie@freebsd.org Subject: Re: Configuration management References: <3A969CD0.DE9E94E1@softweyr.com> <200102232342.QAA01378@usr05.primenet.com> <20010224142406.A23979@roaming.cacheboy.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adrian Chadd wrote: > > On Fri, Feb 23, 2001, Terry Lambert wrote: > > > Even if we stick with "flat text files", and we continue to > > edit them by hand, instead of using a method with subschema > > inforcement which makes non-sensical configurations impossible > > (per Jordan's XML example), the idea that it should be _possible_ > > to easily and efficiently machine parse and write these files > > using a single API, which can be proxied over a network through > > a single data channel, is a valid one. > > Wow. I'm agreeing with Terry here. We worked on this for the Interjet at whistle so Terry has the advantage of having seen prototypes in action and taken part in discussions on it over a long time. Basically a namespace that looks at first glance similar to ASN/SNMP but implemented differently. Ascii storage came into it. A configuration daemon answered all requests for configuration information, and it kept it's state in RAM. It loaded that state at bootup, from an ascii flat file, and saved new versions of that file after transactios were made on the configuration database. We used Soft updates and the atomic nature of rename() along with fsync() to ensure that the database was either before or after a transaction but always consistent. There was a lot more to it, of course, but the concept worked well in practice though we never completely moved all configuration over to it. We generated config files for 3rd party software 'on the fly' from the general configuration database, when we wanted to start such a service. Services had templates into which the extracted data from the database was written. Data had rules associated, and there was the capability to associate data in one part of the tree with data in another for consistancy checking and such. Since there was an 'on the line' spec for how this data looked we could write many different 'back-ends' and 'frontends'. > > I once worked for a large ISP. They had lots and lots of boxes, and > they were able to do stuff like install a custom (in-house modified) > installation of Redhat (or FreeBSD if they really wanted to) which, > when placed on the network, automagically picked up its "role" and > configured itself. It then could continue this "role" with periodic > configuration updates. > > How they did it was evil. They had an SQL database(s) with the > entire network configuration which they then wrote scripts which > would query the database with the machine hostname, pull down > a configuration/to-do-list (eg create account "foo", delete account > "blah", etc..) and then apply these changes locally. > > Each application required a seperate set of scripts to maintain. > I don't think they had a cute way of updating the RPMs on the machines > besides manually doing it, but I'm sure they've solved that one by > now. > > The point is, in order to go from stand-alone UNIX machines to > lots-o-machines and have them manageable and flexible required a hell > of _a lot_ of work. > > Just a case study for y'all, > > Adrian > > -- > Adrian Chadd "Programming is like sex: > One mistake and you have to support for > a lifetime." -- rec.humor.funny > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 9:50: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 6FF4037B401 for ; Sat, 24 Feb 2001 09:49:59 -0800 (PST) (envelope-from netchild@leidinger.net) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14WipQ-0006Hk-00; Sat, 24 Feb 2001 18:49:56 +0100 Received: from b85f3.pppool.de ([213.7.133.243] helo=Magelan.Leidinger.net) by mx3.freenet.de with esmtp (Exim 3.22 #1) id 14WipQ-0004Hw-00; Sat, 24 Feb 2001 18:49:56 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.2/8.11.2) with ESMTP id f1OGvhj03081; Sat, 24 Feb 2001 17:57:44 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200102241657.f1OGvhj03081@Magelan.Leidinger.net> Date: Sat, 24 Feb 2001 17:57:42 +0100 (CET) From: Alexander Leidinger Subject: Re: cvs commit: src/share/mk sys.mk To: bde@zeta.org.au Cc: kris@obsecurity.org, arch@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24 Feb, Bruce Evans wrote: > On Fri, 23 Feb 2001, Kris Kennaway wrote: > >> On Thu, Feb 22, 2001 at 10:53:52PM +0100, Alexander Leidinger wrote: >> > > Hmm, that's not what's documented in the gcc info docs. >> > >> > The docs are wrong. >> > >> > > `-march=CPU TYPE' >> > > Generate instructions for the machine type CPU TYPE. The choices >> > > for CPU TYPE are the same as for `-mcpu'. Moreover, specifying >> > > `-march=CPU TYPE' implies `-mcpu=CPU TYPE'. >> > >> > That's not true, test it on your own (see my previous mail with my test >> > program) if you think the doc is right (or have a look at "man gcc" on a >> > system with gcc 2.95.3 (e.g. a recent -current)). > > No, the docs are correct here. But why are there different md5 sums in Message-ID: <200102221150.f1MBopF07996@Magelan.Leidinger.net>? > Don't look at "man gcc". It is not maintained except by non-FSF > volunteers (see the WARNING section on the first page of it). In > practice, this means that it hasn't changed significantly since > rev.1.1.1.1 in 1994. I know about the differences in "man gcc" and "info gcc", but the documentation for x86 part of -march and -mcpu are significant similar. Bye, Alexander. -- Yes, I've heard of "decaf." What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 10:42:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from androcles.com (androcles.com [204.57.240.10]) by hub.freebsd.org (Postfix) with ESMTP id DA72437B4EC for ; Sat, 24 Feb 2001 10:41:50 -0800 (PST) (envelope-from alex@androcles.com) Received: (from dhh@localhost) by androcles.com (8.11.1/8.11.1) id f1OIffL51320; Sat, 24 Feb 2001 10:41:41 -0800 (PST) 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: Sat, 24 Feb 2001 10:41:41 -0800 (PST) From: "Duane H. Hesser" To: Randell Jesup Subject: RE: ELF and diskless boot Cc: (Bruce Bauman) , (Mike Sinz) , Alfred Perlstein , arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-01 Randell Jesup wrote: > FYI, is there a reason that we've set up our kernel interface to top, etc > to fail unless the kernel (in this case 4.x) is loaded with _debugging_ > symbols? I.e. if you strip a kernel, top (and a bunch of other stuff) > doesn't work because they can't find certain kernel structures. To make > this worse, they also fail if you etherboot (because debug symbols aren't > loaded). > > Is there a reason for this behavior? Perhaps some benefit we don't see? > Any chance of getting this fixed? I believe this appears sometime since > 3.x, i.e. after we'd already moved to ELF, but I'm not sure. > > (Note: I'm not the primary person investigating this; Mike is. I think > he's looking at modding etherboot to work around the problem.) > > -- > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > rjesup@wgate.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > Is the following pertinent? (from the archives, almost a year ago...included without shifts) ======= Start included message ======== Date: Wed, 5 Apr 2000 20:43:55 +0300 From: Ruslan Ermilov To: Bernd Luevelsmeyer Cc: freebsd-questions@FreeBSD.ORG, Sheldon Hearn , Gustavo V G C Rios Subject: Re: nlist failed in 4.0 Message-ID: <20000405204355.D33946@relay.ucb.crimea.ua> In-Reply-To: <38EB6291.6B7BFB75@heitec.net>; from Bernd Luevelsmeyer on Wed, Apr 05, 2000 at 05:58:09PM +0 200 References: <5291.954944534@axl.ops.uunet.co.za> <38EB6291.6B7BFB75@heitec.net> On Wed, Apr 05, 2000 at 05:58:09PM +0200, Bernd Luevelsmeyer wrote: > Sheldon Hearn wrote: > > > > On Tue, 04 Apr 2000 09:01:39 GMT, Gustavo V G C Rios wrote: > > > > > boot into single user and: > > > > > > cd /usr/src > > > make -DNOINFO installworld > > > make installworld > > > exit > > > > This will not solve the problem. > > > > Ciao, > > Sheldon. > > Indeed it doesn't. Using a version 3.anything will work without > /boot/loader; for versions 4.release and 5.yesterday you must let > /boot/loader do its thing. > Or apply the following two patches by Bruce Evans (see attached). By the way, there is an open PR kern/17422 on this issue. -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id SAA44626; Tue, 28 Mar 2000 18:14:30 +0300 (EEST) (envelope-from ru) Date: Tue, 28 Mar 2000 18:14:30 +0300 From: Ruslan Ermilov To: Mikhail Teterin Cc: stable@freebsd.org, Bruce Evans Subject: Re: top, systat )-: (all rebuilt!) Message-ID: <20000328181430.A41307@relay.ucb.crimea.ua> Mail-Followup-To: Mikhail Teterin , stable@freebsd.org, Bruce Evans References: <20000328100840.B7725@relay.ucb.crimea.ua> <200003281453.JAA01102@rtfm.newton> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" X-Mailer: Mutt 0.95.3i In-Reply-To: <200003281453.JAA01102@rtfm.newton>; from Mikhail Teterin on Tue, Mar 28, 2000 at 09:53:20AM -0500 On Tue, Mar 28, 2000 at 09:53:20AM -0500, Mikhail Teterin wrote: > Ruslan Ermilov once stated: > > =Do you use loader(8), or directly boot your kernel from boot blocks? > > Directly... Is that what it is?!? > Yes, starting from the following files/revisions: peter 1999/12/26 23:14:59 PST Modified files: lib/libkvm kvm.c kvm_alpha.c kvm_file.c kvm_getloadavg.c kvm_getswapinfo.c kvm_i386.c kvm_nlist.3 kvm_private.h kvm_proc.c kvm_sparc.c Log: Use kldsym(2) to lookup symbol values. This avoids the kvm_mkdb juggling and is module aware. Yes, this means that kvm_nlist(3) will find symbols in loaded modules. The emulation of the nlist struct is pretty crude but seems to work well enough for all the users in the tree that I found. Revision Changes Path 1.12 +22 -113 src/lib/libkvm/kvm.c 1.4 +1 -2 src/lib/libkvm/kvm_alpha.c 1.9 +5 -0 src/lib/libkvm/kvm_file.c 1.3 +5 -1 src/lib/libkvm/kvm_getloadavg.c 1.10 +1 -2 src/lib/libkvm/kvm_getswapinfo.c 1.11 +5 -1 src/lib/libkvm/kvm_i386.c 1.5 +7 -9 src/lib/libkvm/kvm_nlist.3 1.5 +1 -1 src/lib/libkvm/kvm_private.h 1.25 +7 -2 src/lib/libkvm/kvm_proc.c 1.3 +5 -1 src/lib/libkvm/kvm_sparc.c Could you please try the following two patches (kindly provided by Bruce Evans), and tell us whether they help you. There is a kern/17422 on this issue, please follow-up to it. Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) with ESMTP id EAA76938 for ; Tue, 14 Mar 2000 04:52:39 +0200 (EET) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA05065; Tue, 14 Mar 2000 13:58:35 +1100 Date: Tue, 14 Mar 2000 13:51:49 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Ruslan Ermilov cc: Jordan Hubbard , committers@FreeBSD.org Subject: Re: [4.0-ERRATA candidate?] loader(8)/kvm(3) interoperability issue In-Reply-To: <20000313194345.A52651@relay.ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Mar 2000, Ruslan Ermilov wrote: > One thing that should IMHO be pointed out in the upcoming 4.0-RELEASE's > ERRATA (or some more appropriate place), is the fact that the loader(8) > is now a prerequisite for certain programs using kvm(3) interface. > Obvious examples are top(1) and swapinfo(8). > > If you boot your kernel without loader(8), directly through bootblocks, > these programs will not work. I don't user loader(8), and finally got around to fixing this. The problem is that the kernel linker wants module data for the kernel. It defaults to using incomplete data if none is present. The following supplies slightly less incomplete data: diff -c2 machdep.c~ machdep.c *** machdep.c~ Tue Feb 29 19:18:29 2000 --- machdep.c Mon Mar 6 10:05:52 2000 *************** *** 1809,1812 **** --- 1799,1816 ---- preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE; preload_bootstrap_relocate(KERNBASE); + } else { + static u_int32_t oldmoduledata[] = { + 1, sizeof("kernel"), 0, 0, + 2, sizeof("elf kernel"), 0, 0, 0, + 0x8004, 4, 0, + 0x8003, 4, 0, + 0, 0, + }; + + preload_metadata = (caddr_t)&oldmoduledata[0]; + strcpy((char *)&oldmoduledata[2], "kernel"); + strcpy((char *)&oldmoduledata[6], "elf kernel"); + oldmoduledata[11] = roundup2(bootinfo.bi_esymtab, 4); + oldmoduledata[14] = bootinfo.bi_symtab; } if (bootinfo.bi_envp) Bruce Content-Type: message/rfc822 Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) with SMTP id QAA33103 for ; Wed, 22 Mar 2000 16:34:11 +0200 (EET) (envelope-from bde@zeta.org.au) Received: (qmail 25547 invoked from network); 22 Mar 2000 14:33:30 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 22 Mar 2000 14:33:30 -0000 Date: Thu, 23 Mar 2000 01:33:15 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Ruslan Ermilov Subject: Re: [4.0-ERRATA candidate?] loader(8)/kvm(3) interoperability issue In-Reply-To: <20000321213700.A64137@relay.ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hmm, the kernel with this patch panics with fatal trap 12 earlier, > right after it reports the amount of available memory, if I boot > without loader(8), but works perfectly, if I do use loader(8). The symbol addresses in struct bootinfo were garbage when the symbol table was loaded but DDB was not configured. diff -c2 locore.s~ locore.s *** locore.s~ Mon Dec 6 11:12:51 1999 --- locore.s Thu Mar 23 01:11:57 2000 *************** *** 45,51 **** #include "opt_bootp.h" - #include "opt_ddb.h" #include "opt_nfsroot.h" - #include "opt_userconfig.h" #include --- 45,49 ---- *************** *** 751,756 **** movl $R(_end),%esi ! /* include symbols if loaded and useful */ ! #ifdef DDB movl R(_bootinfo+BI_ESYMTAB),%edi testl %edi,%edi --- 749,753 ---- movl $R(_end),%esi ! /* Include symbols, if any. */ movl R(_bootinfo+BI_ESYMTAB),%edi testl %edi,%edi *************** *** 761,765 **** addl %edi,R(_bootinfo+BI_ESYMTAB) over_symalloc: - #endif /* If we are told where the end of the kernel space is, believe it. */ --- 758,761 ---- Bruce ------------------------------------------------------------------------------- ======== End include message ======== -------------- Duane H. Hesser dhh@androcles.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 12:57:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 8111137B67D; Sat, 24 Feb 2001 12:57:49 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1OKoiH68116; Sat, 24 Feb 2001 12:50:45 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: brooks@one-eyed-alien.net Cc: tlambert@primenet.com, marcel@cup.hp.com, jhb@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] In-Reply-To: <20010223162903.A7882@Odin.AC.HMC.Edu> References: <3A96F984.7233C733@cup.hp.com> <200102240016.RAA02409@usr05.primenet.com> <20010223162903.A7882@Odin.AC.HMC.Edu> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010224125044P.jkh@osd.bsdi.com> Date: Sat, 24 Feb 2001 12:50:44 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Brooks Davis Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] Date: Fri, 23 Feb 2001 16:29:03 -0800 > Darwin uses this or similar support. The people from Apple has stated > that they want fat binary support in openpackages. It's also been I might also note that you don't need to play ELF games to get "fat binary support" in a package system, the idea of a permuted name space inside a package being something I've suggested several times in our PackageToolsNG discussions. Basically, the idea is that if you have a random-access package archive format (or even if you don't, it just being a little more painful then) then you can frob the package directory information in such a way that you encode names and property information into each physical directory entry, similar to the way C++ mangles type/function information into a global symbol space. That way a "fat package" for, say, GNU bash might have a directory which looks something like this: bin/bash@arch=i386 bin/bash@arch=alpha man/man1/bash.1.gz@* info/bash.info@* Where, in this highly contrived example, we assume that everything following an un-escaped @ is the start of the property list information which has to be matched in order for that item to be extracted under its real name. Things with *'s in the example match all extraction criteria. Obviously, one could further extend this to have version-specific properties in order to support multiple versions (perhaps one "stable" and one "development") in a package or option-specific properties, like "no man pages please". A canonical base set of property names and values would obviously have to be agreed upon in order for this to work, but it's a lot easier and far more flexible than using ELF binaries with multiple personalities. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 12:59: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D534A37B401 for ; Sat, 24 Feb 2001 12:58:57 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA18385; Sat, 24 Feb 2001 13:57:41 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA02176; Sat, 24 Feb 2001 13:57:39 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15000.8258.691426.704099@nomad.yogotech.com> Date: Sat, 24 Feb 2001 13:57:38 -0700 (MST) To: Matt Dillon Cc: Tony Finch , Wes Peters , Randell Jesup , Terry Lambert , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND In-Reply-To: <200102230834.f1N8YTg79555@earth.backplane.com> References: <200102200122.SAA04466@usr05.primenet.com> <3A934507.A0645CF3@softweyr.com> <20010223073526.F19285@hand.dotat.at> <200102230834.f1N8YTg79555@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Storing program-specific configuration data for many diverse applications > in a single file is (A) a stupid idea, (B) a stupid idea, and most > importantly (C) ... a stupid idea. So, does that mean we should get rid of /etc/rc.conf? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 15:19:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 6C86A37B67D for ; Sat, 24 Feb 2001 15:19:05 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Wo8N-00027f-00; Sat, 24 Feb 2001 16:29:51 -0700 Message-ID: <3A9843EF.9406F8FB@softweyr.com> Date: Sat, 24 Feb 2001 16:29:51 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Configuration management References: <200102232342.QAA01378@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > Storing program-specific configuration data for many diverse applications > > > in a single file is (A) a stupid idea, (B) a stupid idea, and most > > > importantly (C) ... a stupid idea. Having config parameters all > > > in one place does not magically make the idiot tring to manipulate > > > them any better at his job, but it sure makes it more likely that he > > > will take the whole system down with him when he does make a mistake! > > > > > > Nor does stuffing a GUI on top of said configuration data, no matter where > > it is located, give somebody the experience to operate a complex system. > > Knowing how to do something does not imply knowing what to do. > > > > The lack of a configuration data API, and a common configuration > file layout syntax has been a problem with UNIX since day 1. > > When you learn how to configure one program, the knowledge is > not transferrable over to another program; you must relearn it > for each program, which make UNIX unnecessarily dense, with an > unnecessarily high learning curve, but with no benefit of having > achieved a greater altitude for having climbed N of these curves, > as opposed to N-1 of these curves. > > Further, the lack of a single data channel to which the API talks > means that proxy configuration of a number of machines can't be > done over a network. Nor can one multiplex the proxy stream to > change machine independent data on a large number of machines > simultaneously. Neither can computable machine specific data be > handled this way (e.g. renumbering a network). > > Additionally, when a GUI is provided, even if that GUI is not > a direct representation of the configuration hierarchy, or it > abstracts the complexity to a level usable by an end user at > any given level of capability (as the MVC -- Model, View, > Controller -- paradigm favored by Activity Theory and HCI -- > Human Computer Interaction -- dictates should be done), it is > _gratuitously_ difficult to supply, due to the exhausting number > of back end interfaces which have to be written. > > So _you_ don't want a GUI: BFD. So _you_ don't want to do > cluster configuration: BFD. So _you_ don't want to do role > based configuration of subsets of a cluster spread over > multiple colocation facilities: BFD. > > The point is that just because some people don't see a need > for something doesn't make it useless. Ask the next Amish > person you meet whether or not there should be cars; then > tell me if you're prepared to give up your car, if you have > one. Nothing written in this thread by either myself OR Matt disagreed with anything you wrote; why do you take such an argumentative approach? > Even if we stick with "flat text files", and we continue to > edit them by hand, instead of using a method with subschema > inforcement which makes non-sensical configurations impossible > (per Jordan's XML example), the idea that it should be _possible_ > to easily and efficiently machine parse and write these files > using a single API, which can be proxied over a network through > a single data channel, is a valid one. Nobody said it wasn't. This is, however, one of the dichotomies faced (and not yet handled) by the UNIX community: the importance of a single machine vs. the importance of a large pool of machines. Somebody like Yahoo!, for instance, really wouldn't care much if one of their thousands of machines was currently not booting, but desperately needs to be able to manage those thousands as a single entity. Those running the freebsd.org ftp server, on the other hand, very much need that one machine to be quickly fixable if it does go down, since it is the "crown jewel" in that installation. Your point that facilitating the management of thousands of machines doesn't necessarily destroy the ability to manage one is true, but so far I haven't seen a tool that purports to do the former while preserving the latter. Preserving the latter is critically important to much of the FreeBSD user base; probably more so than managing thousands of machines. I doubt you'll find very many people more experienced at reading and processing the configuration files on different variants of UNIX than I. Having a consistent API for processing such data would certainly improve things, but only if it is done well. Storing configuration data on a server on the network may work if the network is just as important as the server, but that is not the case for the average FreeBSD machine. There is an interesting opportunity here for somebody adventurous and not afraid of hard work to set about converting FreeBSD (or any other source-available operating system) to a test case for a new management framework. Gathering up all the various configuration files or data stores on a system and replacing them with, say, an XML representation of the same data would be an interesting project. Providing legacy APIs, like getpwent, etc., that used the XML format, as well as providing the new API you would like to see would be a straightforward, if somewhat monumental task. This sounds like work for a graduate researcher with some undergrad (i.e. underPAID) programmers at his disposal. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 15:56:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 6E60137B6AC for ; Sat, 24 Feb 2001 15:56:19 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f1ONu6181837; Sat, 24 Feb 2001 15:56:07 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <15000.8258.691426.704099@nomad.yogotech.com> Date: Sat, 24 Feb 2001 15:55:45 -0800 (PST) From: John Baldwin To: Nate Williams Subject: Re: DJBDNS vs. BIND Cc: arch@FreeBSD.org, josb@cncdsl.com, Alfred Perlstein , Terry Lambert , Randell Jesup , Wes Peters , Tony Finch , Matt Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Feb-01 Nate Williams wrote: >> Storing program-specific configuration data for many diverse >> applications >> in a single file is (A) a stupid idea, (B) a stupid idea, and most >> importantly (C) ... a stupid idea. > > So, does that mean we should get rid of /etc/rc.conf? It's the configuration file for /etc/rc. Just one conceptual program. :) It doesn't specify configuration information for the programs that rc runs, just what programs to run. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 17:44:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id B517337B67D; Sat, 24 Feb 2001 17:44:07 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f1P1SNx10209; Sat, 24 Feb 2001 17:28:23 -0800 Date: Sat, 24 Feb 2001 17:28:23 -0800 From: Brooks Davis To: Jordan Hubbard Cc: tlambert@primenet.com, marcel@cup.hp.com, jhb@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] Message-ID: <20010224172823.A9214@Odin.AC.HMC.Edu> References: <3A96F984.7233C733@cup.hp.com> <200102240016.RAA02409@usr05.primenet.com> <20010223162903.A7882@Odin.AC.HMC.Edu> <20010224125044P.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010224125044P.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Sat, Feb 24, 2001 at 12:50:44PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 24, 2001 at 12:50:44PM -0800, Jordan Hubbard wrote: > > Darwin uses this or similar support. The people from Apple has stated > > that they want fat binary support in openpackages. It's also been >=20 > I might also note that you don't need to play ELF games to get "fat > binary support" in a package system, the idea of a permuted name space > inside a package being something I've suggested several times in our > PackageToolsNG discussions. True, but you don't get to take advantage of the space savings this way and you can't have a unified tree without resorting to symlink, filesystem, or auto mounter hacks. With real fat binaries you only have to keep one copy of certain segments or perhaps one copy per endianness, but certaintly less copies then the total number of architectures. If you wanted to just implement fat packages you might actually want to *not* use a ransom access archive format so you could at least get better compression of the repeted segments of the binaries. An intresting tradeoff question. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6mF+2XY6L6fI4GtQRApvIAJwK3bC4KDCQdIct7nSRjsomESV7eACeLMEI wMQEtqaRrAjLW9COAmec2Fo= =I4hl -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 18: 8:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9EA3E37B401; Sat, 24 Feb 2001 18:08:32 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1P28VC10795; Sat, 24 Feb 2001 18:08:31 -0800 (PST) (envelope-from dillon) Date: Sat, 24 Feb 2001 18:08:31 -0800 (PST) From: Matt Dillon Message-Id: <200102250208.f1P28VC10795@earth.backplane.com> To: John Baldwin Cc: Nate Williams , arch@FreeBSD.ORG, josb@cncdsl.com, Alfred Perlstein , Terry Lambert , Randell Jesup , Wes Peters , Tony Finch Subject: Re: DJBDNS vs. BIND References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>> applications :>> in a single file is (A) a stupid idea, (B) a stupid idea, and most :>> importantly (C) ... a stupid idea. :> :> So, does that mean we should get rid of /etc/rc.conf? : :It's the configuration file for /etc/rc. Just one conceptual program. :) :It doesn't specify configuration information for the programs that rc runs, :just what programs to run. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ Right. Sometime it's hard to tell whether people are serious or just being annoying when they post stupid 'does that mean' missifs. Assuming the original poster was serious, I will give a serious answer. But even that is somewhat beside the point because there are always exceptions to the rule in any system... the existance of such exceptions in no way justifies their methodology when applied to general principles or to other matters. Context matters. Files such as /etc/spwd.db (aka /etc/master.passwd) hold very specific, *generally* used information. Just because such files are used by almost every program in the system doesn't mean that they are similar to something like the windoz registry. There are many files in the system that are used everywhere that hold very specific, well defined, generally used information. The password file is only one example. /etc/group, /etc/localtime, /etc/resolv.conf, there are dozens of such files. A file such as /etc/rc.conf may apply to many programs, but it's a read-only typically boot-time-only entity. On top of that, while all the /etc/rc* files reference many different programs, all of the programs and defaults with only a very few exceptions are part of the base system. 99.9% of third party programs don't use /etc/rc.conf directly and don't know it even exists, and entries in rc.conf are typically very small single-line entities. This means that even though the parameters specified in /etc/rc.conf may apply to many different programs, it is still a very far cry from what registry-like system is designed to deal with. One can hardly compare /etc/rc.conf against a registry. In contrast, configuration files such as /etc/namedb/named.conf, /etc/ntp.conf, /usr/local/etc/dhcpd.conf, /etc/mail/sendmail.cf, etc are a very different breed. Each of these files contains relatively complex configuration information for a specific subsystem and the rest of the system never needs to touch them. Only ntpd uses ntp.conf. Only dhcpd uses dhcpd.conf. Only sendmail uses sendmail.cf. Furthermore, these files are not 'config and forget' files like rc.conf. In addition to these configuration files, many subsystems require writable persistent store (and typically use /var/db for that). Under UNIX, it is SOP for these files to be independant of each other. A 'registry' in the context of this thread is meant to replace the second type of file... the named.conf's and ntp.conf's of the world, and a registry might very well be used for the first type of file as well.. but that is secondary. So now we have a centralized, human UNreadable database covering so many subsystems that it is constantly being updated and written to by the system. We require a UI and API to access this 'registry', and the result is that we force subsystems that would otherwise never have any visibility into each others physical data store to now have (A) visibility (e.g. it makes it much easier for a third party program to do 'bad' things to the system... like netscape overwriting IE's registry parameters and vise-versa), and (B) potentially effect another subsystem's operational nature by corrupting the repository, or crashing at just the wrong time, or simply be making the registry an incredibly dangerous place to be due to making constant updates to it. One screw up and it isn't just the subsystem that screwed up that blows up, its the entire system. And this isn't even getting into what happens if a registry-bound dataset for a particular system configuration winds up having to be huge .. say a password file with 50000 users in it. The word 'stupid' doesn't even begin to describe it. So not only is a registry nothing like rc.conf, but for the purposes a registry would be intended the only plus side is having a single API for "everything under the sun" configuration elements and the many negative sides include potential scaleability issues, potential "crash and burn the entire system" issues, potential improper use by one program of another program's configuration elements, the necessity (since a registry is by concept a R+W entity) to add additional complexity to maintain the UNIX security model for use, and if I spent another 5 minutes thinking about it I can probably come up with a dozen other downsides. A single registry in the context of general use in FreeBSD to consolidate the configuration data for many unrelated programs is, simply put, an extremely stupid idea. Now, obviously, we are talking about a registry in a specific context... a registry managing UNIX based programs. And, specifically, FreeBSD. Obviously there are other uses for a registry like entity that aren't 'stupid'. There are many other cool uses for a registry like entity... just none when you take it in the context of tring to consolodate all the configuration info used by programs that run under FreeBSD. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 22:26: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id CD9EC37B4EC for ; Sat, 24 Feb 2001 22:25:56 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Wun2-0002F3-00; Sat, 24 Feb 2001 23:36:16 -0700 Message-ID: <3A98A7DF.3E8FAA57@softweyr.com> Date: Sat, 24 Feb 2001 23:36:15 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: brooks@one-eyed-alien.net, arch@FreeBSD.ORG Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand] References: <3A96F984.7233C733@cup.hp.com> <200102240016.RAA02409@usr05.primenet.com> <20010223162903.A7882@Odin.AC.HMC.Edu> <20010224125044P.jkh@osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > > I might also note that you don't need to play ELF games to get "fat > binary support" in a package system, the idea of a permuted name space > inside a package being something I've suggested several times in our > PackageToolsNG discussions. > > Basically, the idea is that if you have a random-access package > archive format (or even if you don't, it just being a little more > painful then) then you can frob the package directory information in > such a way that you encode names and property information into each > physical directory entry, similar to the way C++ mangles type/function > information into a global symbol space. That way a "fat package" for, > say, GNU bash might have a directory which looks something like this: > > bin/bash@arch=i386 > bin/bash@arch=alpha > man/man1/bash.1.gz@* > info/bash.info@* > > Where, in this highly contrived example, we assume that everything > following an un-escaped @ is the start of the property list > information which has to be matched in order for that item to be > extracted under its real name. That was covered in the discussion on the OP mailing list. It's a workable idea, but doesn't cover the situation of providing i.e. 4 or 5 different architectures in a binary on an NFS server. In this case, you'd want the package installer to rip out the ELF segments for architectures you're not supporting, leaving all that you are. It is interesting to contemplate whether or not you can fold together data segments for any differing architectures. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 24 23:26:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-199.dsl.lsan03.pacbell.net [63.207.60.199]) by hub.freebsd.org (Postfix) with ESMTP id ABEB837B401 for ; Sat, 24 Feb 2001 23:26:39 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4BAD567156; Sat, 24 Feb 2001 23:26:39 -0800 (PST) Date: Sat, 24 Feb 2001 23:26:39 -0800 From: Kris Kennaway To: Bruce Evans Cc: Alexander Leidinger , arch@FreeBSD.ORG Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20010224232638.A6907@mollari.cthul.hu> References: <20010223010514.A41551@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Sat, Feb 24, 2001 at 01:33:14PM +1100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 24, 2001 at 01:33:14PM +1100, Bruce Evans wrote: > > Okay, I've built several binaries and libraries with -march=3Dpentiumpro > > and -march=3Dpentiumpro -mcpu=3Dpentiumpro, and verified with diff -b t= hat > > the output in both cases is indeed identical. It looks like the docs > > are correct. >=20 > ITYM "incorrect". >=20 > This just shows that your tests didn't test the small areas where > -march makes a difference (other than implying -mcpu). Examination > of gcc.295/config/i386/i386.{md,h} shows that it it only mainly (only?) > affects areas related to the i686 fcmov instruction. The following > program uses these areas, so compiling it with -march=3Dpentiumpro and > -mcpu=3Dpentiumpro gives different results: I never disputed that - what I said above was that -march implies -mcpu for i386 code (as documented), therefore for "optimal optimization" we only need -march. The docs say that -mcpu alone does different things to -march, as your test also demonstrates. Kris --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mLOuWry0BWjoQKURAsNpAJ47bvoQqifSTOH7c2ZR4ql9oBgfwwCfSDvY FmqhEOk4xokWd16xg0Li4Uc= =WXKM -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message