Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, Dec 10, 2001 at 05:32:06PM -0600, D J Hawkey Jr wrote: Don't get me wrong - I don't expect the same level of support from the FreeBSD Project than I would from, say, Sybase or Sun. Having said that, I think FreeBSD's is outstanding, even compared to some other commercial *cough*Microsquish(tm)*cough* entities. Yep, that's why we're here. Glad you think so, mind you! My current plans are to have several patchfiles, grouped by subject (bugfix and/or enhancement), and subordinately grouped by FreeBSD release: ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff You get the idea. Mr. Burns voiceExcellent/Mr. Burns voice Other people will help with QA, if this takes off. Believe me, if a patch blows up a system you'll hear about it. Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are outstanding products. I'm just gonna see if I can't fulfill what I percieve as a support deficiency (again, from my own perspective) in my own little way. That's the only way anything gets done around here; someone sees a need, and fills it. The only question is, is this a need? From watching the mailing lists, I certainly think it is. PS, I'm rather honored that such an illustrious group has shown interest enough to even discuss all this with me. You know, I think I'm going to write an article on this, I say it often enough. #include rant.h The FreeBSD group is really not that illustrious. Some of us are -- if Bruce Evans speaks, we all shut up and listen. We are simply the people who do the work. Everything that is done, is done because someone thought there was a need. I got my start in the FreeBSD community back in 1999 by writing articles. This isn't something that *directly* benefits the Project; it adds nothing to the CVS repo, and doesn't get me the coveted @freebsd.org email address. It's important, however, and something that I am very well-qualified to do. So I shut up, and did it. It got me a certain amount of recognition and respect in the community, it was fun, and it satisfied my itch to solve a problem. There is a huge amount of basic grunt work that can be done. Nobody bothers to do it, so it doesn't happen. People such as you and I can ease a vital gap by simply picking some little hole, and doing the work to fill it. It's not glamorous. It's not exciting. But it lets people like $YOURFAVORITECODECOMMITTER get on with stuff that only they can do. Lots of people say that they want to help. Lots of people make suggestions. Some make suggestions that are well beyond their ability to perform. In this case, those suggestions are usually either obvious (Hey, wouldn't it be cool if FreeBSD supported FireWire?) or clueless (Why don't we have a kernel option READMYMINDANDDOWHATIWANT?). These suggestions are generally ignored; both would be good ideas, but one requires convincing a developer to pick it up and the other is brain-dead. Some suggestions are within the ability of the people making the suggestion. Posting on a mailing list and saying Hey, would this be a good idea? is a great way to tell if you have a boneheaded idea, or if you have a serious need. Your case is a great example of this. You can't expect a thousand people to write back and say Oh, it's a good idea. This is a public discussion board, and everyone on it gets far too much email as-is. If we read something we agree with, we aren't going to all post me too! But if you get a few people publically agreeing with you, and nobody says Your idea sucks!, you can generally assume that it's a decent idea. Once you have buy-in, go *DO IT*. I've seen a lot of decent ideas come across the FreeBSD mailing lists since 1996. Most of them die on the vine. The point is this: J D, you have an idea. Your messages have been read by most of the readers of this mailing list. You have gotten a do it! from a few people, including a -core member. You have gotten a few side comments from other developers, such as Matt Dillon's comment on your future in the flame wars. So, people have actually read this thread. I might be wrong, but I don't believe that you have received a message saying Your idea sucks! You have also received a few comments on other ways this can be handled; this should be taken in the spirit in which it is meant, which is It's a good idea, here's how you could improve it. In FreeBSD, this is what passes for management buy-in. This is not the first time I've seen this idea on this mailing list. I sincerely, devoutly hope that it is the last. So, I officially challenge you: are you going to do it, or is this going to wither on the vine like every other time it's been suggested? Consider the gauntlet thrown (in the kindest possible manner, mind you). Put up an initial patchset, announce it here and on,
Re: Tangent for discussion: FreeBSD performs worse that Linux
Geez. Don't some of you sleep, either? On Dec 11, at 06:14 AM, Michael Lucas wrote: My current plans are to have several patchfiles, grouped by subject (bugfix and/or enhancement), and subordinately grouped by FreeBSD release: ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff You get the idea. Mr. Burns voiceExcellent/Mr. Burns voice Well, as Mr. Watson pointed out, there are better ways, but for an initial rollout, I don't think that level of sophistication is required. Other people will help with QA, if this takes off. Believe me, if a patch blows up a system you'll hear about it. :-) Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are outstanding products. I'm just gonna see if I can't fulfill what I percieve as a support deficiency (again, from my own perspective) in my own little way. That's the only way anything gets done around here; someone sees a need, and fills it. The only question is, is this a need? From watching the mailing lists, I certainly think it is. The point is this: J D, you have an idea. D J, actually. But Dave or Hawk gets my attention faster. Your messages have been read by most of the readers of this mailing list. You have gotten a do it! from a few people, including a -core member. You have gotten a few side comments from other developers, such as Matt Dillon's comment on your future in the flame wars. So, people have actually read this thread. I might be wrong, but I don't believe that you have received a message saying Your idea sucks! You have also received a few comments on other ways this can be handled; this should be taken in the spirit in which it is meant, which is It's a good idea, here's how you could improve it. In FreeBSD, this is what passes for management buy-in. So, I officially challenge you: are you going to do it, or is this going to wither on the vine like every other time it's been suggested? Consider the gauntlet thrown (in the kindest possible manner, mind you). Put up an initial patchset, announce it here and on, say, daily.daemonnews.org, list an email address for patches on the web page, and see what happens. No challenge necessary. I, too, believe the general attitude is Go for it.. So I'm going to. It won't be much to look at initially - maybe ever - but I'll bring it up and see what happens. It'll take a few days, but I'll post an It's here. when it's here. BTW, am I allowed to use the daemon mascot? I spent some time yesterday browsing cvs-all@, and got another little patch that backported easily and fixed a nagging problem I've had since day two (that AGP patch in the above example). In fact, if you do it well, you might even find a vaguely well-known BSD columnist picking up your site in a future article. Ack. Don't do that. Sooner or later, the economy will pick up again, I'll get myself the badly-needed job I lost, and my play-time will once again be reduced by a factor of four. The last thing I'll need then is any kind of publicity. ==ml Thanks for all the encouragement and feedback, Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote: J D, you have an idea. D J, actually. But Dave or Hawk gets my attention faster. Mea culpa. Please blame this on four hours sleep, followed by four hours blindly running Oracle's adpatch before the DBAs arrive... Personally, I respond to just about anything, including Hey, Loser! In fact, if you do it well, you might even find a vaguely well-known BSD columnist picking up your site in a future article. Ack. Don't do that. Sooner or later, the economy will pick up again, I'll get myself the badly-needed job I lost, and my play-time will once again be reduced by a factor of four. The last thing I'll need then is any kind of publicity. Well, hang on here a second. I'd say you want publicity for exactly that reason. Eventually, you'll move on to other things. We want someone else to pick up when you depart. I strongly recommend you plan for your successor to come along. Don't worry about who that person is, just leave them an opening. Some poor slob who is hooked on your service will have no choice but to handle it when you're too busy to, and the whole community will benefit. :) For example, I'm working on the FAQ right now. If you check various parts of the FAQ, you'll see that they were originally maintained by jkh, nik, and a long list of other people, all at different times. They would want someone to pick up where they left off. At some point, someone will succeed me as the FAQ interested party. ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, Dec 10, 2001 at 03:24:14PM -0600, D J Hawkey Jr wrote: Doesn't mean that you need 100% coverage though. If you produce something that only gets in 80% of the patches that could be applied back that's still better than what we have now. And it makes it easier for someone else to help out with the missing 20%. Huh? You completely list me with this. Are you trying to say that some feature of a patch that applies to just the last three of four prior releases is OK, 'cuz right now none are (except for security fixes to RELENG_(current - 1))? I meant that any effort you put in is better than none. For example, if you decide to start producing patches for 4.4 that bring in some features from -stable (e.g., delayed acks) that's far better than you not doing it at all. Don't feel that because you can't do everything you want to do that you shouldn't do any of it. If you get the ball rolling, and become known as *the* place to go for extra patches, you'll find that other people start sending you additional patches to include. Pretty soon we'll get bored of having people ask Hey, why aren't these patches in RELENG_4_4 (or whatever) and we'll corral you in to becoming a committer so that you can make this an 'official' part of FreeBSD. So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. It's a start. What's the URL? You're kidding, right? I only started thinking about doing this yesterday! The patches are sitting right here, in $(HOME)/projects. OK. Well, if you put them up on a web site, we can link to them. If you can think of appropriate other places on the FreeBSD web site to mention them then we can do that too. Don't be put off because you want to start small. . . N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg29969/pgp0.pgp Description: PGP signature
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 11, at 07:14 PM, Nik Clayton wrote: I meant that any effort you put in is better than none. For example, if you decide to start producing patches for 4.4 that bring in some features from -stable (e.g., delayed acks) that's far better than you not doing it at all. As others have also said. Yup. Don't feel that because you can't do everything you want to do that you shouldn't do any of it. If you get the ball rolling, and become known as *the* place to go for extra patches, you'll find that other people start sending you additional patches to include. Oh, no. I don't have a problem with starting small. I wasn't born 6'0, after all. I am rather hoping there's a bunch of packrats lurking in hacker@ that might mail me their backports. It'd make a better initial impression. I don't have any pretentions or aspirations of being the place to go for backports. If it happens, it happens. Pretty soon we'll get bored of having people ask Hey, why aren't these patches in RELENG_4_4 (or whatever) and we'll corral you in to becoming a committer so that you can make this an 'official' part of FreeBSD. Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap, and an @freebsd.org mail addy. :-) So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. It's a start. What's the URL? You're kidding, right? I only started thinking about doing this yesterday! The patches are sitting right here, in $(HOME)/projects. OK. Well, if you put them up on a web site, we can link to them. If you can think of appropriate other places on the FreeBSD web site to mention them then we can do that too. The page is half-built now. If freebsd.org wants to link to the page (or any other BSD sites, for that matter) that's OK with me. Linking to the individual patchfiles pro'lly isn't a good idea. For those that're interested (and have the time), it's at http://www.visi.com/~hawkeyd/freebsd-backports.html for review/critique. It's only a WIP at this point; please don't do anything to publicize it. I'll mail hackers@ again when it's done, for final review/ critique. N Let the flaming begin! Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote: I am rather hoping there's a bunch of packrats lurking in hacker@ that might mail me their backports. It'd make a better initial impression. Let me disabuse you of that notion right now. You're it. Most people in -hackers fall into two groups: 1) track -stable 2) track -current You're it. Congrats. Put up what you've got. Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap, and an @freebsd.org mail addy. :-) Nope. Just an @freebsd.org mail addy and a coupon for economy-size Maalox. Sorry. Put up what you've got. For those that're interested (and have the time), it's at http://www.visi.com/~hawkeyd/freebsd-backports.html for review/critique. It's only a WIP at this point; please don't do anything to publicize it. I'll mail hackers@ again when it's done, for final review/ critique. Oh. Well, okay, you put up what you got. poke at site Good start, now let's get some patches up there. :) -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 11, at 04:23 PM, Michael Lucas wrote: On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote: I am rather hoping there's a bunch of packrats lurking in hacker@ that might mail me their backports. It'd make a better initial impression. Let me disabuse you of that notion right now. You're it. Most people in -hackers fall into two groups: 1) track -stable 2) track -current You're kidding. A whole bunch of folk, all dedicated to an OS, and nobody's got patch archives?? *Sheesh* mutterNOW what'd I get myself into? The wife is gonna kill me./mutter You're it. Congrats. Put up what you've got. Only if I get BSD daemon badges for my machines, a BSD sweatshirt or cap, and an @freebsd.org mail addy. :-) Nope. Just an @freebsd.org mail addy and a coupon for economy-size Maalox. Sorry. Put up what you've got. OK, I'll take the addy (what's the convention, initials? Mine are djhjr). The freebsd.org mailserver is POP3able, right? But I'll swap the coupons for daemon PC badges. I don't do over-the-counter drugs. All right, all right. A twelve-pack of Guiness. In cans; the bottled stuff is too flat. poke at site Good start, now let's get some patches up there. :) That'll be the time-consuming part. Not the posting of 'em, but describing 'em. I want that part to be as concise as possible. You don't mind if a few others weight in, do you? I can spell, but I'd like opinion on the language vis-a-vis the targetted audience. And some legal kinda guy or girl. I don't know if the disclaimer is adequate protection. Michael Lucas Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
D J Hawkey Jr [EMAIL PROTECTED] types: On Dec 11, at 04:23 PM, Michael Lucas wrote: On Tue, Dec 11, 2001 at 03:04:59PM -0600, D J Hawkey Jr wrote: I am rather hoping there's a bunch of packrats lurking in hacker@ that might mail me their backports. It'd make a better initial impression. Let me disabuse you of that notion right now. You're it. Most people in -hackers fall into two groups: 1) track -stable 2) track -current You're kidding. A whole bunch of folk, all dedicated to an OS, and nobody's got patch archives?? *Sheesh* You can find my patch archives at URL: http://www.FreeBSD.org/cgi/query-pr-summary.cgi :-) Basically, I submit patches as prs. Those that I consider really important I'll keep around until the PR gets dealt with. I've as yet to have something that was both important enough for me to keep separately and closed without being added to the base code. Why keep it myself when I can get it added to the base system? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Tue, Dec 11, 2001 at 03:54:44PM -0600, D J Hawkey Jr wrote: On Dec 11, at 04:23 PM, Michael Lucas wrote: mutterNOW what'd I get myself into? The wife is gonna kill me./mutter Well, yes. Nope. Just an @freebsd.org mail addy and a coupon for economy-size Maalox. Sorry. Put up what you've got. OK, I'll take the addy (what's the convention, initials? Mine are djhjr). The freebsd.org mailserver is POP3able, right? Sorry, I've misspoke here: A lot of people volunteer to do this sort of thing, and never really carry it through. This sadly happens often enough that we don't give out the email addresses until there's actual stuff that gets out there, maintained for a while, and integrated into the project. My sincere apologies for implying anything else. (The following is in no way about you in particular, Hawk; it's just an unfair characterization we're stuck with, because it seems to fit the facts.) Unfortunately, many people start things and never finish them, or don't see them through. Since @freebsd.org is one of the few things we have to offer committers, we don't hand them out to people who are starting things. (If more people actually carried through, I'm sure this would change.) I started doing things is 1999, but got a commit bit last month. Admittedly, most of those didn't go directly into the project. Yours, I suspect, will get picked up quickly if you can coordinate it well. You don't mind if a few others weight in, do you? I can spell, but I'd like opinion on the language vis-a-vis the targetted audience. And some legal kinda guy or girl. I don't know if the disclaimer is adequate protection. Seriously, it's your project. Involve as many people as you want. You are in change. (That's the hardest thing to get used to with this project.) -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 11, at 05:52 PM, Michael Lucas wrote: OK, I'll take the addy (what's the convention, initials? Mine are djhjr). The freebsd.org mailserver is POP3able, right? Sorry, I've misspoke here: A lot of people volunteer to do this sort of thing, and never really carry it through. This sadly happens often enough that we don't give out the email addresses until there's actual stuff that gets out there, maintained for a while, and integrated into the project. My sincere apologies for implying anything else. [SNIP] Hey, it's OK. I understand. Don't sweat it. Michael Lucas Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote: No challenge necessary. I, too, believe the general attitude is Go for it.. So I'm going to. It won't be much to look at initially - maybe ever - but I'll bring it up and see what happens. It'll take a few days, but I'll post an It's here. when it's here. BTW, am I allowed to use the daemon mascot? I currently have the domains mybsd.(com|net|org|biz). If you'd like the patch database to be associated with any or all of those domains, I'd be happy to oblige. (The hostname patch.mybsd.com is pretty. ; ) I've been trying to figure out what to do with these for quite a while. Perhaps this is an opportunity. Ack. Don't do that. Sooner or later, the economy will pick up again, I'll get myself the badly-needed job I lost, and my play-time will once again be reduced by a factor of four. The last thing I'll need then is any kind of publicity. Ah, but with fame can come fortune. Once you're widely known as The Man for customizing FreeBSD, you can double your consulting rates, thereby doubling the free time you can allocate to the library. ;-) p -- Paul Chvostek [EMAIL PROTECTED] Operations / Development / Abuse / Whatever vox: +1 416 598- IT Canadahttp://www.it.ca/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 11, at 08:17 PM, Paul Chvostek wrote: I currently have the domains mybsd.(com|net|org|biz). If you'd like the patch database to be associated with any or all of those domains, I'd be happy to oblige. (The hostname patch.mybsd.com is pretty. ; ) Indeed. Quite clever. I'll consider this, and get back to you. On Tue, Dec 11, 2001 at 05:48:19AM -0600, D J Hawkey Jr wrote: Ack. Don't do that. Sooner or later, the economy will pick up again, I'll get myself the badly-needed job I lost, and my play-time will once again be reduced by a factor of four. The last thing I'll need then is any kind of publicity. Ah, but with fame can come fortune. Once you're widely known as The Man for customizing FreeBSD, you can double your consulting rates, thereby doubling the free time you can allocate to the library. ;-) Heh. I'll consider this, too. p Thanks, Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 09, at 05:26 PM, Michael Lucas wrote: On Sun, Dec 09, 2001 at 12:17:03PM -0600, D J Hawkey Jr wrote: So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. Everything starts somewhere. When I wrote my first FreeBSD article a few years ago, I had no idea where it would lead. Keep it up, and the Project might well ask you to make it an official FreeBSD resource. If you start now, in a few months you'll have patchsets for 4.2-R, 4.3-R, 4.4-R, and 4.5-R. That looks like a pretty serious investment of time and/or dedication to me. Yup. To me, too. But as I said, without some sort of barometer I can read that tells me what's going on with -STABLE or -CURRENT that is even half- way portable and worthwhile to previous releases, I'm afraid it'd be a rather stale resource pretty quickly. Ideally, it would be grand if the hackers/committers could mail me the patches they make to -STABLE, and I could then backport them to previous releases, where possible. Just so I'm not read as someone on the fence, I am prepared to make public the patches I've made (as well as those from others), but there are considerable hurdles to be worked out: - They would be patches against whatever is in place on a machine at a particluar time. If it was something-REL, they might not apply cleanly to something-STABLE or something-HACKED. At a bare minimum, this implies that the user/admin be well-acquainted with the syntax of unified diffs, and the basics of code discovery. - After such patches are applied, how does one guard against a subsequent 'cvsup' blowing away these private updates. That is, someone applies my patch for ICH sound to their 4.3REL base. How can that source be protected against a 'cvsup RELENG_4_3' upgrade, which will overwrite those patched files? These two points alone might (should?) scare off all but the most anal of SysAdmins. If such a resource was available (patches site), it seems to me the target audience would be quite small, indeed. One of the things I'm really asking (without explicitely stating so) is, How can such a site, more specifically, it's content, be made sufficiently painless to install? I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. It's cliche, but: ten thousand lines of code begins with the first #define. (H click click click... okay, style(9) says it should be the first #include. But you get the idea.) Actually, the first part of a source module should be The Abstract. :-) Michael Lucas Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: hi, does anyone need any special skills to manage the kind of branch you are talking about... example.. RELENG_4_4_BUGFIX what kind of skills and experience in FreeBSD would be needed for this kind of branch I'm still confused about what this branch would contain; bug fixes to 4.4REL? Isn't that what -STABLE is all about? I could maintain a not-FreeBSD-sanctioned site for patches of -CURRENT and -STABLE code applyable to previous releases, but that would only muddy the FreeBSD maintenance and distribution waters that I think work well for what they're intended to address, as well as open myself up to all sorts of support and maintenance headaches. i wouldn't mind helping :-) Consider yourself enlisted. :-) What sorts of skills/interests have you to offer? I'm a pretty fair C coder, and can comfortably play with shell, awk, and sed scripts, too. I'm already involved in a few global projects, so I'm not too bad at managing/applying/supplying submissions. And guess what? I can write man pages and other documentation, too! I have web/ftp space available at my ISP (midwest USA), and it has some pretty fat pipes. Some logistics and details still need to be worked out before I/we really start anything (I hope to work them out in this thread, if I'm not kicked out for being off-topic). -Hiten, Is that pronounced with a long or short 'i'? Dave -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
[this is a re-post; apparently my first didn't take?] On Dec 09, at 05:26 PM, Michael Lucas wrote: On Sun, Dec 09, 2001 at 12:17:03PM -0600, D J Hawkey Jr wrote: So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. Everything starts somewhere. When I wrote my first FreeBSD article a few years ago, I had no idea where it would lead. Keep it up, and the Project might well ask you to make it an official FreeBSD resource. If you start now, in a few months you'll have patchsets for 4.2-R, 4.3-R, 4.4-R, and 4.5-R. That looks like a pretty serious investment of time and/or dedication to me. Yup. To me, too. But as I said, without some sort of barometer I can read that tells me what's going on with -STABLE or -CURRENT that is even half- way portable and worthwhile to previous releases, I'm afraid it'd be a rather stale resource pretty quickly. Ideally, it would be grand if the hackers/committers could mail me the patches they commit to -STABLE, and I could then backport them to previous releases, where possible. But, I could easily see this overwhelming me in very short order! Just so I'm not read as someone on the fence, I am prepared to make public the patches I've made (as well as those from others), but there are considerable hurdles to be worked out: - They would be patches against whatever is in place on a machine at a particluar time. If it was something-REL, they might not apply cleanly to something-STABLE or something-HACKED. At a bare minimum, this implies that the user/admin be well-acquainted with the syntax of unified diffs, and the basics of code discovery. - After such patches are applied, how does one guard against a subsequent 'cvsup' blowing away these private updates. That is, someone applies my patch for ICH sound to their 4.3REL base. How can that source be protected against a 'cvsup RELENG_4_3' upgrade, which will overwrite those patched files? These two points alone might (should?) scare off all but the most anal of SysAdmins. If such a resource was available (patches site), it seems to me the target audience would be quite small, indeed. One of the things I'm really asking (without explicitely stating so) is, How can such a site, more specifically, it's content, be made sufficiently painless to install? I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. It's cliche, but: ten thousand lines of code begins with the first #define. (H click click click... okay, style(9) says it should be the first #include. But you get the idea.) Actually, the first part of a source module should be The Abstract. :-) Michael Lucas Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, Dec 10, 2001 at 07:41:51AM -0600, D J Hawkey Jr wrote: [this is a re-post; apparently my first didn't take?] Nope, we got it. As penance for re-sending, your penance is to implement the ideas discussed below. :-) On Dec 09, at 05:26 PM, Michael Lucas wrote: Yup. To me, too. But as I said, without some sort of barometer I can read that tells me what's going on with -STABLE or -CURRENT that is even half- way portable and worthwhile to previous releases, I'm afraid it'd be a rather stale resource pretty quickly. Not necessarily. Read cvs-all. Grab interesting updates (such as the recent TCP changes) and see if they compile. Some will, some won't. If you become known as Mr. MFS for old releases, people will start sending you sligtly modified patches based on their work, and it will take off. Or, the public will decide they aren't interested, and it won't. In either case, the next time you start a project you'll be taken far more seriously. - They would be patches against whatever is in place on a machine at a particluar time. If it was something-REL, they might not apply cleanly to something-STABLE or something-HACKED. At a bare minimum, this implies that the user/admin be well-acquainted with the syntax of unified diffs, and the basics of code discovery. - After such patches are applied, how does one guard against a subsequent 'cvsup' blowing away these private updates. That is, someone applies my patch for ICH sound to their 4.3REL base. How can that source be protected against a 'cvsup RELENG_4_3' upgrade, which will overwrite those patched files? Valid concerns. You should definitely post this on the web page. These two points alone might (should?) scare off all but the most anal of SysAdmins. If such a resource was available (patches site), it seems to me the target audience would be quite small, indeed. One of the things I'm really asking (without explicitely stating so) is, How can such a site, more specifically, it's content, be made sufficiently painless to install? Hmmm... I think you're stuck with patch. If you have your patches properly arranged, however, you can make the patch very simple to install. cd /usr/src patch /home/admin/4.1R-patchset.diff make buildkernel installkernel I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. Well, 4.1 is rather elderly. If you support the older ones, and make your techniques available for other people, you might well find that someone else supports 4.4 for you. Or, just keep your eyes open for a used hard drive you can scarf from somewhere. Heck, someone at work offered me a 20 gig drive for free because he'd just updated to a 120-gig drive. Unfortunately, I didn't take him up on it or I'd ship it to you, hopefully solving the hardest issue. This could take a lot of time, but I think a lot of people would thank you for it. ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 10, at 08:50 AM, Michael Lucas wrote: On Mon, Dec 10, 2001 at 07:41:51AM -0600, D J Hawkey Jr wrote: [this is a re-post; apparently my first didn't take?] Nope, we got it. As penance for re-sending, your penance is to implement the ideas discussed below. :-) You did, eh? Hmm. It didn't show up in the INN mirror I monitor (sol.net Network Services, Milwaukee, WI). Sorry. On Dec 09, at 05:26 PM, Michael Lucas wrote: Yup. To me, too. But as I said, without some sort of barometer I can read that tells me what's going on with -STABLE or -CURRENT that is even half- way portable and worthwhile to previous releases, I'm afraid it'd be a rather stale resource pretty quickly. Not necessarily. Read cvs-all. Grab interesting updates (such as the recent TCP changes) and see if they compile. Some will, some won't. I'll look for this. If you become known as Mr. MFS for old releases, people will start sending you sligtly modified patches based on their work, and it will take off. Or, the public will decide they aren't interested, and it won't. In either case, the next time you start a project you'll be taken far more seriously. Well, this'd be my third global project. But the other two are rather obscure. - They would be patches against whatever is in place on a machine at a particluar time. If it was something-REL, they might not apply cleanly to something-STABLE or something-HACKED. At a bare minimum, this implies that the user/admin be well-acquainted with the syntax of unified diffs, and the basics of code discovery. - After such patches are applied, how does one guard against a subsequent 'cvsup' blowing away these private updates. That is, someone applies my patch for ICH sound to their 4.3REL base. How can that source be protected against a 'cvsup RELENG_4_3' upgrade, which will overwrite those patched files? Valid concerns. You should definitely post this on the web page. I thought I read somewhere that the cvsup config file had options to support protecting source modules, but I pro'lly didn't read it right. Setting file attributes as read-only would work, but the possibility then exists that some module wouldn't be updated that really ought to be, or that cvsup would fail altogether. Or, let cvsup overwrite the patched modules, and the user/admin would have to re-apply the patches, which would likely generate rejects. Grr. If there's an upshot to this, it is that only still-supported releases fall into this trap, -STABLE and RELENG_(release - 1). Well, other hackers like me, who patch their systems independantly, could also have problems. Hmmm... I think you're stuck with patch. If you have your patches properly arranged, however, you can make the patch very simple to install. As long as the user/admin understands that the patch is very target- specific, yes. If the target has moved a little, though, things may well get a bit hairy. I guess I don't want caveat emptor as the fallback position I would have to assume, though I'd make myself available to help with such cases. I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. Well, 4.1 is rather elderly. If you support the older ones, and make your techniques available for other people, you might well find that someone else supports 4.4 for you. Hopefully. And yes, the rather elderly would be potential targets. Isn't that the point of all this, after all? This could take a lot of time, but I think a lot of people would thank you for it. I take it you, for one, would like to see this take off. I make it two. Another in this thread volunteered his involvement. That's enough for me; I'll give it a shot. When I've got the site up, who (or what mailing list) do I want to notify? ==ml As they say, Thank you for your support. Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, Dec 10, 2001 at 08:29:12AM -0600, D J Hawkey Jr wrote: You did, eh? Hmm. It didn't show up in the INN mirror I monitor (sol.net Network Services, Milwaukee, WI). Sorry. Ah, INN. It made it to the mailing list. As long as the user/admin understands that the patch is very target- specific, yes. If the target has moved a little, though, things may well get a bit hairy. I guess I don't want caveat emptor as the fallback position I would have to assume, though I'd make myself available to help with such cases. Well, here's something most people don't really realize: caveat emptor is the default FreeBSD fallback position. We don't guarantee any support of our product. These higher-level admins you worry about should know darn well the implications of their actions. And there's always a worst-case fallback; blow away /usr/src and reinstall from known good media. Hopefully. And yes, the rather elderly would be potential targets. Isn't that the point of all this, after all? True. My point is, you must start somewhere. When I've got the site up, who (or what mailing list) do I want to notify? If at all possible, take out a full-page ad in the New York Times. FreeBSD could really use the exposure. Failing that, a posting on this list would be fine. :) ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Sun, Dec 09, 2001 at 12:17:03PM -0600, D J Hawkey Jr wrote: Seems to me that were I to do this, and I would, it would only be as viable as the patches themselves. That is, I (and any contributors) would have to be able to stay abreast of those things going on in -STABLE that could get backported to previous releases (could being a significant word here). Well, yeah. That's pretty much a pre-requisite. Doesn't mean that you need 100% coverage though. If you produce something that only gets in 80% of the patches that could be applied back that's still better than what we have now. And it makes it easier for someone else to help out with the missing 20%. So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. It's a start. What's the URL? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg29898/pgp0.pgp Description: PGP signature
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, 10 Dec 2001, D J Hawkey Jr wrote: I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. For 4.3-RELEASE, there's a RELENG_4_3 branch in CVS that security fixes are committed to; you'd probably want to generate patches with respects to the head of the RELENG_4_3 branch so as not to have to duplicate the security bug fixes, only the non-security ones that don't go into RELENG_4_3. Otherwise, you'd lose out on some of the more desirable bug fixes :-). Note also that as a release gets older, it drops off the security-officer supported list, due to a gradual increase in the level of work required to support the release. This tends to happen when a major subsystem has to be replaced in order to fix the bug, rather than a minor tweak being sufficient. For example, the death of RELENG_3 from the SO perspective was when ncurses had to be replaced, rather than patched, to cover all known holes. This required relinking of countless binaries, making a binary update relatively infeasible, and requiring a high level of investment in order to update past changed APIs. How fast the window runs out on a release depends on what needs fixing, so it's hard to predict when it will happen. Having the release branches has made generating security updates far more efficient, and permitted us to handle a binary update model for userland binaries. Without version control in place, as it wasn't for this stuff for a long time, it was very hard to generate relative patches, manage large numbers of patchsets for various versions, or keep any notion of binary updates in order. It doesn't fix the windowing issue, but it does make it easier to deal with. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 10, at 08:00 AM, Nik Clayton wrote: On Sun, Dec 09, 2001 at 12:17:03PM -0600, D J Hawkey Jr wrote: Seems to me that were I to do this, and I would, it would only be as viable as the patches themselves. That is, I (and any contributors) would have to be able to stay abreast of those things going on in -STABLE that could get backported to previous releases (could being a significant word here). Well, yeah. That's pretty much a pre-requisite. Doesn't mean that you need 100% coverage though. If you produce something that only gets in 80% of the patches that could be applied back that's still better than what we have now. And it makes it easier for someone else to help out with the missing 20%. Huh? You completely list me with this. Are you trying to say that some feature of a patch that applies to just the last three of four prior releases is OK, 'cuz right now none are (except for security fixes to RELENG_(current - 1))? So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. It's a start. What's the URL? You're kidding, right? I only started thinking about doing this yesterday! The patches are sitting right here, in $(HOME)/projects. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 10, at 03:34 PM, Robert Watson wrote: On Mon, 10 Dec 2001, D J Hawkey Jr wrote: I can backport to 4.2REL and 4.3REL (I have these releases), but I don't have the resources (read: free partitions) to accomodate 4.1 or 4.4. For 4.3-RELEASE, there's a RELENG_4_3 branch in CVS that security fixes are committed to; you'd probably want to generate patches with respects to the head of the RELENG_4_3 branch so as not to have to duplicate the security bug fixes, only the non-security ones that don't go into RELENG_4_3. Otherwise, you'd lose out on some of the more desirable bug fixes :-). Good point. Note also that as a release gets older, it drops off the security-officer supported list, due to a gradual increase in the level of work required to support the release. [SNIP] How fast the window runs out on a release depends on what needs fixing, so it's hard to predict when it will happen. Understood. [SNIP] So, my question is then, just what is the policy defining non-current-but- still-supported-releases? Right now, these is exactly one such release, 4.3, for security fixes. Will there always be exactly one, such that when 4.5 is released, 4.3 will fall off the planet, and 4.4 takes its place? Or might there be two, 4.3 and 4.4? This comes 'round to one of my original questions, too: Why, as an example, isn't the DELACK patches Matt made recently considered important enough to be backported to RELENG_4_3 (which I have more generically referred to as RELENG_(current - 1) or RELENG_(release - 1))? It has been said that a fix might be backported to RELENG_(current - 1) that isn't necessarily a security issue; can't that be expanded to any (or perhaps just major) fixes that don't imply a new feature of RELENG_(current)? Yes, I know this would mean additional work on the part of the hacker and committer, but is it not better they do it, than the likes of me, an user/ admin that isn't necessarily in a position to stay -STABLE, but knows enough of C and patch(1) to pro'lly get things right most of the time? The problem with the latter is that I can't possibly know of what's getting fixed in -STABLE (or -CURRENT), or the severity of the fixes, without considerably more effort than that of the former. Then, I still might not get it right, just 'cuz I'm not the expert the hacker/committer is. The site Michael and I have discussed will be hugely deficient in terms of what can be made available to any previous release (compared to what is applied to -STABLE), but as it sits right now, it would be better than nought for those that can't stay -STABLE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, Dec 10, 2001 at 03:59:24PM -0600, D J Hawkey Jr wrote: Right now, these is exactly one such release, 4.3, for security fixes. Will there always be exactly one, such that when 4.5 is released, 4.3 will fall off the planet, and 4.4 takes its place? Or might there be two, 4.3 and 4.4? As far back as possible. Bad answer, I know, but it's much like the answer for 3.x. :( This comes 'round to one of my original questions, too: Why, as an example, isn't the DELACK patches Matt made recently considered important enough to be backported to RELENG_4_3 (which I have more generically referred to as RELENG_(current - 1) or RELENG_(release - 1))? It has been said that a fix might be backported to RELENG_(current - 1) that isn't necessarily a security issue; can't that be expanded to any (or perhaps just major) fixes that don't imply a new feature of RELENG_(current)? Because DELACK isn't a security problem. It's a performance problem. It's a serious performance problem, but not a security problem. They had to draw the line somewhere, and since the security-officer group is supporting this they get to call the shots. If you do a good enough job, perhaps you can wind up supporting this in the main source tree. :) The site Michael and I have discussed will be hugely deficient in terms of what can be made available to any previous release (compared to what is applied to -STABLE), but as it sits right now, it would be better than nought for those that can't stay -STABLE. Bingo. Something is better than nothing. -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, 10 Dec 2001, D J Hawkey Jr wrote: So, my question is then, just what is the policy defining non-current-but- still-supported-releases? Right now, these is exactly one such release, 4.3, for security fixes. Will there always be exactly one, such that when 4.5 is released, 4.3 will fall off the planet, and 4.4 takes its place? Or might there be two, 4.3 and 4.4? It depends on the level of work required, I expect. Right now, we're actively supporting 4.3-RELEASE and 4.4-RELEASE. Once we get to a point where the cost is greater than can be handled by our all-volunteer staff, we'll cut back. Currently, my hope is that we can keep supporting all branches of 4.x-RELEASE through to 5.0-RELEASE next year. If we try to avoid doing too many releases, that will be easier :-). This comes 'round to one of my original questions, too: Why, as an example, isn't the DELACK patches Matt made recently considered important enough to be backported to RELENG_4_3 (which I have more generically referred to as RELENG_(current - 1) or RELENG_(release - 1))? It has been said that a fix might be backported to RELENG_(current - 1) that isn't necessarily a security issue; can't that be expanded to any (or perhaps just major) fixes that don't imply a new feature of RELENG_(current)? Yes, I know this would mean additional work on the part of the hacker and committer, but is it not better they do it, than the likes of me, an user/ admin that isn't necessarily in a position to stay -STABLE, but knows enough of C and patch(1) to pro'lly get things right most of the time? The problem with the latter is that I can't possibly know of what's getting fixed in -STABLE (or -CURRENT), or the severity of the fixes, without considerably more effort than that of the former. Then, I still might not get it right, just 'cuz I'm not the expert the hacker/committer is. The quick answer is: because the security-officer team is using the RELENG_4_x branches to generate binary updates, and has extremely limited resources. As such, the only things being merged onto the branch are security fixes. If the release engineering team is willing to take over the task of generating binary updates, and wants to broaden the scope of the branch, then such a proposal might make more sense. The goal of creating the branches was to permit version control to be applied to a series of updates that were previously being managed by hand: security patches. Using CVS allows the security-officer team to make the resulting patches more reproduceable, allows tag management for patchlevels, etc. While I'm sympathetic to the cause of we want a -NOT-AS-AGRESSIVE-AS-STABLE-BUT-NOT-JUST-SECURITY-FIXES, I think our resources are already spread too thin to support that. If we were to move to a model where the branch was maintained by re@, who generated binary updates based on commits to the branch, and managed the QA process, looking at a broader scope of potential commits might be feasible. In such a scenario, the SO would work with re@ to get security fixes into the branch, but the re@ team would do the leg-work for updates and release notes. The site Michael and I have discussed will be hugely deficient in terms of what can be made available to any previous release (compared to what is applied to -STABLE), but as it sits right now, it would be better than nought for those that can't stay -STABLE. I think in practice you'll find what is needed is the ability to do local revision management in the form of branches. You may want to investigate version control software other than CVS, in that case. A number of consumers of FreeBSD, such as Yahoo!, make use of Perforce, importing the FreeBSD CVS repo hourly into a vendor branch. They can then maintain local changes relative to that branch easily. Note that you'd still be left with a heavy burden, however: QA. Part of the currently goal of RELENG_4_x is that each change be extensively tested, and usable by a wide audience with low levels of concern about picking up potentially conflicting changes. Most of the changes are very small, and as such have a higher probability of correctness. Broadening the charter for the release branch would mean expanding the QA process. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 10, at 05:21 PM, Robert Watson wrote: On Mon, 10 Dec 2001, D J Hawkey Jr wrote: So, my question is then, just what is the policy defining non-current-but- still-supported-releases? [SNIP] It depends on the level of work required, I expect. Right now, we're actively supporting 4.3-RELEASE and 4.4-RELEASE. Once we get to a point where the cost is greater than can be handled by our all-volunteer staff, we'll cut back. Currently, my hope is that we can keep supporting all branches of 4.x-RELEASE through to 5.0-RELEASE next year. If we try to avoid doing too many releases, that will be easier :-). Don't get me wrong - I don't expect the same level of support from the FreeBSD Project than I would from, say, Sybase or Sun. Having said that, I think FreeBSD's is outstanding, even compared to some other commercial *cough*Microsquish(tm)*cough* entities. This comes 'round to one of my original questions, too: Why, as an example, isn't the DELACK patches Matt made recently considered important enough to be backported to RELENG_4_3 (which I have more generically referred to as RELENG_(current - 1) or RELENG_(release - 1))? [SNIP] Yes, I know this would mean additional work on the part of the hacker and committer ... [SNIP] The quick answer is: because the security-officer team is using the RELENG_4_x branches to generate binary updates, and has extremely limited resources. As such, the only things being merged onto the branch are security fixes. If the release engineering team is willing to take over the task of generating binary updates, and wants to broaden the scope of the branch, then such a proposal might make more sense. The goal of creating the branches was to permit version control to be applied to a series of updates that were previously being managed by hand: security patches ... While I'm sympathetic to the cause of we want a -NOT-AS-AGRESSIVE-AS-STABLE-BUT-NOT-JUST-SECURITY-FIXES, I think our resources are already spread too thin to support that. If we were to move to a model where the branch was maintained by re@, who generated binary updates based on commits to the branch, and managed the QA process, looking at a broader scope of potential commits might be feasible. [SNIP] I understand. I also understand that my questions and suggestions have the benefit of 20/20 hindsight. The site Michael and I have discussed will be hugely deficient in terms of what can be made available to any previous release (compared to what is applied to -STABLE), but as it sits right now, it would be better than nought for those that can't stay -STABLE. I think in practice you'll find what is needed is the ability to do local revision management in the form of branches. [SNIP] My current plans are to have several patchfiles, grouped by subject (bugfix and/or enhancement), and subordinately grouped by FreeBSD release: ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff You get the idea. It will be all over the web page(s) that the patches are very narrowly targetted, and will list all the usual paranoia steps that should be taken for a decent fallback position should something fail. I have no intention of trying to emulate the FreeBSD model - not that it's not worth emulating, but rather, I simply don't have the resources. Unless it proves overwhelming, I do plan on offering my help in applying patches to the newbie/clueless. or to already hacked sources. Finally, it will be perfectly clear on the web page(s) that what is presented is not endorsed or supported by The Project, blah-blah-woof-woof. left with a heavy burden, however: QA. Part of the currently goal of RELENG_4_x is that each change be extensively tested, and usable by a wide audience with low levels of concern about picking up potentially conflicting changes. Most of the changes are very small, and as such have a higher probability of correctness. Well, I can't provide that level of QA, of course. I can and do run systems with these patches in place, and I pick my targets carefully. I'm not about to backport something like DIRPREFs, but things more discreet/isolated, like ICH sound and delayed ACKs, I can wrap my arms around with fair confidence that I won't muck up something else. C is no stranger to me, and I've hacked/patched a lot of source. I still maintain an X WM that's over ten years old now. Hacking FreeBSD offers one advantage over that - cross-platform compatability isn't an issue! Broadening the charter for the release branch would mean expanding the QA process. And, had the Core 20/20 foresight, it might well have chosen that path, no? Granted, any one patch (and therefore, release) might well take longer to complete, but continued
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Mon, 10 Dec 2001, D J Hawkey Jr wrote: Don't get me wrong - I don't expect the same level of support from the FreeBSD Project than I would from, say, Sybase or Sun. Having said that, I think FreeBSD's is outstanding, even compared to some other commercial *cough*Microsquish(tm)*cough* entities. Sounds good to me :-). My current plans are to have several patchfiles, grouped by subject (bugfix and/or enhancement), and subordinately grouped by FreeBSD release: ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff You get the idea. It will be all over the web page(s) that the patches are very narrowly targetted, and will list all the usual paranoia steps that should be taken for a decent fallback position should something fail. I have no intention of trying to emulate the FreeBSD model - not that it's not worth emulating, but rather, I simply don't have the resources. Unless it proves overwhelming, I do plan on offering my help in applying patches to the newbie/clueless. or to already hacked sources. Finally, it will be perfectly clear on the web page(s) that what is presented is not endorsed or supported by The Project, blah-blah-woof-woof. Small patches for things like the delayed ack should be no problem. Unfortunately, many of the features I've been interested in back-porting in the past have been big features. That's why my boxes are about split between 4.4-RELEASEpXXX and 4.4-STABLE. Broadening the charter for the release branch would mean expanding the QA process. And, had the Core 20/20 foresight, it might well have chosen that path, no? Granted, any one patch (and therefore, release) might well take longer to complete, but continued previous-release support would be more do-able. In terms of investing resources in QA, I'd rather put those resources into making sure new releases were good, and that the upgrade process was clean so that people could get to the next release easily. As we spin up for 4.5-RELEASE, any insight into that process would be much appreciated -- there's a freebsd-qa mailing list if you're interested (and not already subscribed). Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are outstanding products. I'm just gonna see if I can't fulfill what I percieve as a support deficiency (again, from my own perspective) in my own little way. I don't mean to discourage you either -- rather, to explain why we haven't done some of the things you're looking at in the past. And if you manage to do it with resounding success, I certainly plan to encourage you to keep doing it. -STABLE has become a widely-supported tradition, and if there are people interested in helping make continuing support for releases easier, it could no doubt become a similarly widely-supported tradition. PS, I'm rather honored that such an illustrious group has shown interest enough to even discuss all this with me. Hey, I tend to think of us more as victims than illustrious. The FreeBSD core team is currently an elected body, and the members had to nominate themselves for election. That might put them in the category of witting victims, to be contrasted with unwitting victims, who are normally accorded some additional leniency in judgement. I think you'll also find that there's not much difference between core team members and normal FreeBSD developers. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
: :Dave : :PS, I'm rather honored that such an illustrious group has shown interest :enough to even discuss all this with me. Ha! Just wait until witness one of the many flame wars. First we put two people in the ring and one gets thrown to the lions, then everyone else jumps into the ring and throws the other guy to the lions, then the lions get LOOSE and blood and guts wind up splattered all over the place. And THEN everyone picks their virtual guts off the floor and start the whole thing all over again :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 10, at 08:22 PM, Matthew Dillon wrote: : :Dave : :PS, I'm rather honored that such an illustrious group has shown interest :enough to even discuss all this with me. Ha! Just wait until witness one of the many flame wars. First we put two people in the ring and one gets thrown to the lions, then everyone else jumps into the ring and throws the other guy to the lions, then the lions get LOOSE and blood and guts wind up splattered all over the place. And THEN everyone picks their virtual guts off the floor and start the whole thing all over again :-) HAAA-HAA-Ha-ha-aaa. Hey, every family has their squabbles. Heck, our family doesn't even need the lions. In fact, they run to the basement, tails slung low, and hide! -Matt Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Tangent for discussion: FreeBSD performs worse that Linux
On Dec 09, at 12:11 AM, Matthew Dillon wrote: In anycase, your patches look fine. In fact, you not only applied my fixes you also applied a fix in the delayed-ack check that was made (by someone else) some time after 4.2Rel -- the callout_pending() check in DELAY_ACK() fixed a serious bug in prior releases all by itself. Kudos! I know it's been discussed before, but if this is considered a serious bug, shouldn't it also be applied to supported-but-not-stable versions? RELENG_(release - 1) seems to be the target of backported security fixes, and I have no problem with that - a line has to be drawn somewhere - but I (and likely many others) would love to see things such as this (things that aren't security focused) be made to RELENG_(release - 1). If I hadn't caught the DELACK thread on this list, I never would have known that TCP/IP throughput could be fixed/enhanced so easily - for me, that is, I only applied a patch, but pro'lly not for Matt. Another candidate for this sort of thing I'd like to see backported to RELENG_(release - 1) would be DIRPREFS, but that might be asking too much; I don't know how many modules were hacked for that. I took it upon myself to add ICH sound support to my 4.2REL kernel and another 4.3REL kernel, based on the original patches submitted. This is an example of what pro'lly could be omitted from RELENG_(release - 1), but a FreeBSD.org sanctioned facility where the likes of us unsupported- or-supported-but-not-stable hackers could upload/submit patches would be a nice thing. Just my two-cents' worth of thoguht food. Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
I think what would be cool would be to have a RELENG_4_4_BUGFIX tree which was for bugfixes, but was feature frozen. It shouldn't get new features like dirprefs (otherwise its difficult to differentiate it from -STABLE itself) but it should get bugfixes. That way FreeBSD would wind up with some extremely stable and feature frozen code. Unfortunately, I'm not qualified to volunteer to engineer such a branching scheme... On Sun, 9 Dec 2001, D J Hawkey Jr wrote: On Dec 09, at 12:11 AM, Matthew Dillon wrote: In anycase, your patches look fine. In fact, you not only applied my fixes you also applied a fix in the delayed-ack check that was made (by someone else) some time after 4.2Rel -- the callout_pending() check in DELAY_ACK() fixed a serious bug in prior releases all by itself. Kudos! I know it's been discussed before, but if this is considered a serious bug, shouldn't it also be applied to supported-but-not-stable versions? RELENG_(release - 1) seems to be the target of backported security fixes, and I have no problem with that - a line has to be drawn somewhere - but I (and likely many others) would love to see things such as this (things that aren't security focused) be made to RELENG_(release - 1). If I hadn't caught the DELACK thread on this list, I never would have known that TCP/IP throughput could be fixed/enhanced so easily - for me, that is, I only applied a patch, but pro'lly not for Matt. Another candidate for this sort of thing I'd like to see backported to RELENG_(release - 1) would be DIRPREFS, but that might be asking too much; I don't know how many modules were hacked for that. I took it upon myself to add ICH sound support to my 4.2REL kernel and another 4.3REL kernel, based on the original patches submitted. This is an example of what pro'lly could be omitted from RELENG_(release - 1), but a FreeBSD.org sanctioned facility where the likes of us unsupported- or-supported-but-not-stable hackers could upload/submit patches would be a nice thing. Just my two-cents' worth of thoguht food. Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 09, at 08:54 AM, Lamont Granquist wrote: I think what would be cool would be to have a RELENG_4_4_BUGFIX tree which was for bugfixes, but was feature frozen. It shouldn't get new features like dirprefs (otherwise its difficult to differentiate it from -STABLE itself) but it should get bugfixes. That way FreeBSD would wind up with some extremely stable and feature frozen code. Well, this isn't exactly where I was going. The gist of my post was to try to see if some official mechanism(s) could be built to enhance and extend (cough) previous releases beyond the RELENG_(release - 1) security upgrade policy introduced with the 4.3 and 4.4 releases. Besides, aren't you describing the CVS snapshots known as RELEASEs? Unfortunately, I'm not qualified to volunteer to engineer such a branching scheme... I could maintain a not-FreeBSD-sanctioned site for patches of -CURRENT and -STABLE code applyable to previous releases, but that would only muddy the FreeBSD maintenance and distribution waters that I think work well for what they're intended to address, as well as open myself up to all sorts of support and maintenance headaches. Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Sun, Dec 09, 2001 at 11:15:23AM -0600, D J Hawkey Jr wrote: I could maintain a not-FreeBSD-sanctioned site for patches of -CURRENT and -STABLE code applyable to previous releases, but that would only muddy the FreeBSD maintenance and distribution waters that I think work well for what they're intended to address, as well as open myself up to all sorts of support and maintenance headaches. Actually, that's probably the best thing you could do. Because then it shows that you've got the commitment to do this sort of thing and maintain it. The project isn't short of people having good ideas, it's short of people willing to do the actual work. If you do this, and show that the idea is viable, it will be much easier to come back in a few months time to get these patches integrated in to the various RELENG_* branches, and to bring you in as a committer. I'm sure we can make sure that any site you set up to do this is linked to from the FreeBSD web site. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg29838/pgp0.pgp Description: PGP signature
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Dec 09, at 05:51 PM, Nik Clayton wrote: On Sun, Dec 09, 2001 at 11:15:23AM -0600, D J Hawkey Jr wrote: I could maintain a not-FreeBSD-sanctioned site for patches of -CURRENT and -STABLE code applyable to previous releases, but that would only muddy the FreeBSD maintenance and distribution waters that I think work well for what they're intended to address, as well as open myself up to all sorts of support and maintenance headaches. Actually, that's probably the best thing you could do. Because then it shows that you've got the commitment to do this sort of thing and maintain it. The project isn't short of people having good ideas, it's short of people willing to do the actual work. If you do this, and show that the idea is viable, it will be much easier to come back in a few months time to get these patches integrated in to the various RELENG_* branches, and to bring you in as a committer. The viability thing is the catch, no? Seems to me that were I to do this, and I would, it would only be as viable as the patches themselves. That is, I (and any contributors) would have to be able to stay abreast of those things going on in -STABLE that could get backported to previous releases (could being a significant word here). With bugs@, hackers@, stable@, current@, and cross-referencing the CVS tree(s) against these lists, just staying abreast of things seems pretty daunting. I'm sure we can make sure that any site you set up to do this is linked to from the FreeBSD web site. So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. N Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
hi, does anyone need any special skills to manage the kind of branch you are talking about... example.. RELENG_4_4_BUGFIX what kind of skills and experience in FreeBSD would be needed for this kind of branch -Hiten I could maintain a not-FreeBSD-sanctioned site for patches of -CURRENT and -STABLE code applyable to previous releases, but that would only muddy the FreeBSD maintenance and distribution waters that I think work well for what they're intended to address, as well as open myself up to all sorts of support and maintenance headaches. i wouldn't mind helping :-) = -Hiten, Thank You, Yours Sincerely, Hiten Pandya, [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
On Sun, Dec 09, 2001 at 12:17:03PM -0600, D J Hawkey Jr wrote: So far, I've made three patchfiles that can be applied to 4.2REL and 4.3REL. Not exactly the repertoire one would need to garner interest and momentum. Everything starts somewhere. When I wrote my first FreeBSD article a few years ago, I had no idea where it would lead. Keep it up, and the Project might well ask you to make it an official FreeBSD resource. If you start now, in a few months you'll have patchsets for 4.2-R, 4.3-R, 4.4-R, and 4.5-R. That looks like a pretty serious investment of time and/or dedication to me. It's cliche, but: ten thousand lines of code begins with the first #define. (H click click click... okay, style(9) says it should be the first #include. But you get the idea.) ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
