Date: Thu, 25 Jul 2019 00:25:30 +0100 From: Igor Mozolevsky <mozolevsky@gmail.com> To: Robert Simmons <rsimmons0@gmail.com> Cc: "Aaron C. de Bruyn" <aaron@heyaaron.com>, freebsd security <freebsd-security@freebsd.org>, Luke Crooks <luke@solentwholesale.com> Subject: Re: Old Stuff Message-ID: <CADWvR2jpvBe4WBq2gaL966MM13zACpZMpB19HbhsE=-VXMpjnQ@mail.gmail.com> In-Reply-To: <CA%2BQLa9DK9UOC1uSrLQEn4-QpX4t11hJMYCCCn6g4Jb1ogUaBXg@mail.gmail.com> References: <CA%2BQLa9DnEmC0fK81rHGCsuextpN%2BUjMbraUFKBz0DYeDbz%2BTjg@mail.gmail.com> <CAC0r6X-8YpghSCcLAMKtYy=ZTGHZbvMhX7f1Gk5ZQiE92QbEVQ@mail.gmail.com> <CA%2BQLa9BbR9iox5UJr99fZqv=eFm4H6jePDUeKBQ0yq8LhYBMKA@mail.gmail.com> <CAEE%2BrGqLhp2Khe_fFhwmTtUxMkF%2BmTacdbcg_P12HZgSpfdGqw@mail.gmail.com> <CA%2BQLa9DK9UOC1uSrLQEn4-QpX4t11hJMYCCCn6g4Jb1ogUaBXg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Jul 2019 at 20:09, Robert Simmons wrote: > > Yes, to reduce the code base complexity so that resources can be focused on > a smaller code base. > > On Wed, Jul 24, 2019 at 3:06 PM Aaron C. de Bruyn > wrote: > > > Ubuntu made the decision, then rolled it back (partially) due to community > > outcry. (https://itsfoss.com/ubuntu-19-10-drops-32-bit-support/) > > If your reason for wanting to drop support is "Ubuntu is doing it", my > > response would be "cool story bro". > > Can you state what you are trying to accomplish by dropping support so the > > merits can be debated? > > > > -A <snip> Please don't top post, makes replying in context a major PITA! Optimise resource allocation for the code base by writing better code, not by dropping functional parts---code should be simple so as to make errors obvious, and yes, that includes proper design comments in the code too (compare solaris code when that was released to _even current_ FreeBSD code---developers in the former went through painstaking process to explain even the "obvious" things in *plain English,* where as with most FOSS the approach is "well, duh!!! it's obvious why bother writing up???" and the answer is: "it might be obvious now, but (a) how do I know the code reflects the coder's intent, (b) that intent was correct in the first place, and (c) how much do you have to re-learn when you come back to the code in a month, or a year (and I'm not even talking about someone else trying to figure out what the code does when the coder `disappears')?") The short of it is---write quality code, not look for things to trim, if you want better quality software. We had similar discussion already when Rust was being discussed a while back, and one of the "big" reasons was "better," yet it's demonstrably equally easy to write crappy code in the latter. -- Igor M.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2jpvBe4WBq2gaL966MM13zACpZMpB19HbhsE=-VXMpjnQ>