Date: Wed, 18 May 2005 07:48:05 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: Alexander@Leidinger.net Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-queue.c Message-ID: <20050518.074805.26964549.imp@bsdimp.com> In-Reply-To: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> References: <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> <20050517.123715.74710629.imp@bsdimp.com> <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net>
Alexander Leidinger <Alexander@Leidinger.net> writes:
: Warner Losh <imp@bsdimp.com> wrote:
:
: > From: Alexander Leidinger <Alexander@Leidinger.net>
: >> And I haven't seen a technical reason why the classic way of doing
: >> it is bad.
: >> Did I missed it or do I have to say "I don't get it"?
: >
: > It is better because it uses tools in your build tree, rather than
: > what's installed on the system. For development, the classic way is
: > as good as the new way. But for upgrades and such, you can get into
: > lots of trouble when config or binutils, etc change.
:
: Users of -current are supposed to read current@. And they are supposed to
: /usr/src/UPDATING. Major changes to binutils at least provoke a HEADS-UP
: message in current@ (at least they did in the past). And major changes to
: config result in a message about mismatching versions if you run an old
: config binary.
In the past we took this attitude. However, there were *SO* many
questions about why the build was broken that we introduced
buildkernel/installkernel. Once we did that, the number of questions
dropped to almost zero. Since I used to answer a bunch of them, and I
started UPDATING to help with the FAQ, I can tell you we're running at
about 10% the previous layers. It is a safe way to build the kernel
that always works. And we've also seen the ability for more people in
the user community to answer other people's questions. It really has
been a big win.
Also, most of our users, even those running current, get scared at the
slightest hint of a problem. They aren't kernel experts, but like
running current. When they see config mismatch, they literally do not
know what to do.
: Changes to other subsystems which make the old or new userland incompatible
: with the new or old kernel are typically announced too.
Typically? Hardly. Sometimes, yes. But not all the time. It also
varies with time. Some months are good, some are bad.
: So typically (updating from a not too old previos version of current) it
: doesn't matter which way you use as long as you carefully use the offered
: resources. And we've survived with this procedure for a long time (I survive
: since ELF-day, and even when I had some hickups I always got it working again
: with kernel.old, loader.old and so on).
Carefully. Most of our users aren't careful. I mean no disrespect by
that, but they have better things to do with their time than to bother
with this week's workaround for building FreeBSD.
: This is like "the telnet problem". Alot of people yell at you that you have
: to use ssh and telnet is evil. But telnet is an useful tool and there are
: situations where it is ok to use telnet because it can't hurt you in those
: situations. I generally object to badmouthing tools in every situation, when
: there are valid uses for this tool. I favour teaching the people where it is
: ok and where it isn't ok to use such tools, and I show allergic reactions
: when someone exhibits this "everything is evil" behavior. I hope this lets
: you understand why I "promote" the old behavior here.
This is a non-sequitor. The new kernel targets produced real,
tangable results. If you want to use the old ways, feel free. Just
don't complain when they break, which they do with far too frequency.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050518.074805.26964549.imp>