Date: Mon, 10 Dec 2001 08:29:12 -0600 From: D J Hawkey Jr <hawkeyd@visi.com> To: Michael Lucas <mwlucas@blackhelicopters.org> Cc: hackers@freebsd.org Subject: Re: Tangent for discussion: FreeBSD performs worse that Linux Message-ID: <20011210082912.A29365@sheol.localdomain> In-Reply-To: <20011210085038.A29274@blackhelicopters.org>; from mwlucas@blackhelicopters.org on Mon, Dec 10, 2001 at 08:50:38AM -0500 References: <20011209100855.A22942@sheol.localdomain> <20011209084620.V14858-100000@coredump.scriptkiddie.org> <20011209111523.A23357@sheol.localdomain> <20011209175137.B13554@clan.nothing-going-on.org> <20011209121703.A23726@sheol.localdomain> <20011209172652.A25745@blackhelicopters.org> <20011210074151.A29219@sheol.localdomain> <20011210085038.A29274@blackhelicopters.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. / __________________/
\________________/\ hawkeyd@visi.com /\________________/
http://www.visi.com/~hawkeyd/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011210082912.A29365>