Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Apr 2010 17:11:31 -0400
From:      Miles Nordin <carton@Ivy.NET>
To:        freebsd-sparc64@freebsd.org
Subject:   Re: freebsd-update(8) under sparc64? Why is it not available?
Message-ID:  <oqiq7wfkak.fsf@castrovalva.Ivy.NET>
In-Reply-To: <t2v9dd082311004092052mae35776fy17d679542bd5ba0@mail.gmail.com> (Royce Williams's message of "Fri, 9 Apr 2010 19:52:22 -0800")
References:  <4BA9C0AC.3080801@wooh.hu> <20100324075709.GC13561@lonesome.com> <20100324223809.GA34342@alchemy.franken.de> <4BAB4AB9.2090908@buffalo.edu> <1269526260.2007.3.camel@main.lerwick.hopto.org> <20100325233558.GI20888@alchemy.franken.de> <4BACCC0C.7010401@freebsd.org> <oqsk75p5t2.fsf@castrovalva.Ivy.NET> <20100410015309.GB19697@lonesome.com> <t2v9dd082311004092052mae35776fy17d679542bd5ba0@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--pgp-sign-Multipart_Mon_Apr_12_17:11:31_2010-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "rw" == Royce Williams <royce.williams@gmail.com> writes:

    rw> Miles' point appears to be that some end users do not have the
    rw> resources necessary to set up a sufficiently beefy sparc64
    rw> build system to respond quickly to security announcements.

Colin's position is totally ridiculous: people offer build resources
of exotic, heavy, power-hungry hardware to the FreeBSD project, which
already has scripts and frameworks for producing timely builds, but he
believes these offers are conterproductive because individual users
acting separately and without these resources will bumble their way
into developing their own scripts and frameworks to do updates much
faster, so long as they're not demobilized from this natural task
through ``training.''  Where does such implausible belief come from?

``I find the builds boring, and they're more trouble than you'd
think---please, someone else more interested do them, far away from
me'' strikes me as a fine reason to avoid mucking with a platform
that's twice as dead this year as it was last year, but the stated
reason is silly mind-twisting obstructionism, and I don't know how
anyone can get anything done when such beliefs come naturally.

    rw> But it could have been said in a more constructive manner.

Not in my experience.  It sounds like the argument's been going on for
several years, so restating the same position in a literal sense will
get a repetition of the same deluded responses, which is not
constructive at all.

The only thing I can think of more constructive might be, ``can I have
a copy of all your scripts, please.  I'll do my own releases---I just
want a head-start on what few solved gotchya's with the build process
you've found, and then I'll alter the scripts to integrate with my
smart power strip to kick off builds from a work queue at bootup and
shut the machine off when the build finishes,'' but I would expect to
hear ``I will not give you the scripts because your having and using
them will train people to <blah blahblah SKIP blah blahblah SKIP
blah blahblah>.''

    rw> people who would run sparc64 on slow hardware facing the
    rw> public Internet without being willing and able to disconnect
    rw> it when something serious was announced are already doing
    rw> other foolish things

You would not believe how much foolish behavior there is on the
Internet, and updates are always a nightmare since regressions can
take down services just as well as security breaches.  It's a
complicated issue.

But I have never heard anyone say, ``what we really need to push
security updates out faster and with fewer regressions, is fewer
automated update tools.  Have everyone build 'em from source, with
'cvs update' and bmake.  Yah, that's what'll tighten up our ship.''
it's totally crazy.

    rw> "It may be that there's no way to break that 1-hour barrier.
    rw> Maybe I can convince Colin that, until full cross-compiling is
    rw> available, we sparc64 folks would settle for slightly-delayed
    rw> binary security updates (instead of never getting them at
    rw> all).  It's the very fact that we're running on slower
    rw> hardware that makes freebsd-update so attractive."

yeah, what you said, three years ago.

good luck, everyone.

--pgp-sign-Multipart_Mon_Apr_12_17:11:31_2010-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUAS8OMg4nCBbTaW/4dAQK/9QP/at/L1Ck65ItbD01gvsHdx/yJCvlGcCyo
LwcwkBDBysbsgnLWGXjEGdT58NRNEnHBAJYTG2Pb535FFK26Yu87TMB6NcN5ncz7
pPe6nVccXlPLUH2r9RqWm0yTVjld0Yw/RV2OwlLxdNUBPTl79C5WNvPE7iNsBLNs
m2vDY9m90hE=
=yhQe
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Apr_12_17:11:31_2010-1--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?oqiq7wfkak.fsf>