Date: Sun, 17 May 2020 09:41:37 -0600 From: "Dale Scott" <dalescott@shaw.ca> To: "'John Howie'" <john@thehowies.com>, "'@lbutlr'" <kremels@kreme.com> Cc: "'FreeBSD'" <freebsd-questions@freebsd.org> Subject: RE: [FreeBSD-Announce] FreeBSD 12.0 end-of-life Message-ID: <000901d62c61$a7b9cd70$f72d6850$@shaw.ca> In-Reply-To: <7BB197EB-5A5C-47D7-903A-BAE7E7F4D66F@thehowies.com> References: <20200217231452.717FA1E820@freefall.freebsd.org> <CAFYkXjmZi1-MB6W0HsMx9gHek7Xg5heoSKKWkNTnw74dxRTwAw@mail.gmail.com> <85E7C97E-EF8B-4FC7-8EF1-758B7BCBAE90@kreme.com> <05112EEC-7FA3-4E18-974B-263A58058E01@kicp.uchicago.edu> <332714B8-2798-42CF-A082-9EDA180CC65B@kreme.com> <20200516201923.8676289a.freebsd@edvax.de> <257EF587-92B5-4671-B6F4-89E86CC2ACA0@kreme.com> <12062767-7DF1-45FE-A464-C864F03CBDCF@thehowies.com>, <CAB45262-B12E-4C6C-9560-5DEE90628C60@kreme.com> <7BB197EB-5A5C-47D7-903A-BAE7E7F4D66F@thehowies.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> As for =E2=80=9Cperfection is the enemy of good=E2=80=9D, please tell = me you will willingly step into a 737-MAX with its > original s/w because it is =E2=80=9Cgood enough=E2=80=9D. There are = plenty of real world examples where perfection > should be mandatory, and good is not enough. Fully agree in principle, although I would say "we" have learned just = demanding perfection (and testing for) is not practical, and instead = demand proof of _striving_ for perfection (i.e. safety regulated = industries and risk-based compliance requirements). > I may be wrong, but I get the feeling I have been in the software = industry longer than you, and maybe it is just m > age talking, but we are arrogant in thinking that we can get away with = Minimum Viable Product, and (shudder) > =E2=80=9Cfail forward=E2=80=9D Agile methodology.=20 Well said! I hope you don't mind if you hear me use your example. :-)=20 -----Original Message----- From: owner-freebsd-questions@freebsd.org = [mailto:owner-freebsd-questions@freebsd.org] On Behalf Of John Howie Sent: Sunday, May 17, 2020 2:49 AM To: @lbutlr <kremels@kreme.com> Cc: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life Respectfully, you missed my points, and your counterpoints are the = regular industry talking points for why we cannot solve the problem.=20 As for =E2=80=9Cperfection is the enemy of good=E2=80=9D, please tell me = you will willingly step into a 737-MAX with its original s/w because it = is =E2=80=9Cgood enough=E2=80=9D. There are plenty of real world = examples where perfection should be mandatory, and good is not enough. I may be wrong, but I get the feeling I have been in the software = industry longer than you, and maybe it is just my age talking, but we = are arrogant in thinking that we can get away with Minimum Viable = Product, and (shudder) =E2=80=9Cfail forward=E2=80=9D Agile methodology. = Maybe, just maybe, we should take a step back and reconsider what we are = trying to achieve. John Sent from my iPhone > On May 16, 2020, at 23:25, @lbutlr <kremels@kreme.com> wrote: >=20 > =EF=BB=BFOn 16 May 2020, at 13:12, John Howie <john@thehowies.com> = wrote: >> Respectfully, the views presented are not in line with desired state. >=20 > It is in line with reality. >=20 >> We *should* be able to install s/w and forget it until the hardware = eventually fails. >=20 > If the software is hardened and unmodifiable and there is no possible = way for it be exploited, sure. But that is pretty much a fantasy for any = complicated software like an OS. >=20 >> We are building a house of cards with tiered dependencies and = upgrades are often fatal, resulting in prolonged outages. This leads = administrators to just leave systems be. That represents significant = risk. >>=20 >> We need to build better software, and that starts with simplicity. We = need to stop putting everything, including the kitchen sink, into = releases. We need to focus on code quality. Where we absolutely must = update a system we should, by now, be able to hot patch it. The fact = that as an industry we cannot is scandalous. We need to support = distributions for many, many years.=20 >=20 > Software needs to balance between doing what is needed (which means. = Keeping up with new technology, new use cases, new media types, etc) and = being stable and secure. >=20 > If you insist that every thing be perfect from the start, you have = nothing. Because perfect is the enemy of good. >=20 >> These are not FreeBSD-specific issues, but these are golden = opportunities for FreeBSD to stand out from the crowd by releasing = minimalist distributions, with high-quality software that is supported = for many years, and includes the ability to hot patch vulnerable code. >=20 > You make something that has so far proved to be basically impossible = sound super simple. If the software can be =E2=80=98hot fixed=E2=80=99 = then the software can be modified. If it can be modified, then it must = be secure. If it must be secure, you need to be able to fix bugs in the = security and fix new-found exploits and move to newer security models. >=20 > There is a reason we no longer use SSL, and that is a good thing. >=20 >=20 >=20 >=20 > -- > 'Yeah, well, I didn't sign up for world domination,' said Medium > Dave. 'That sort of thing gets you into trouble.' = =E2=80=94Hogfather >=20 >=20 > _______________________________________________ > freebsd-questions@freebsd.org mailing list=20 > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" _______________________________________________ freebsd-questions@freebsd.org mailing list = https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000901d62c61$a7b9cd70$f72d6850$>