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 <aaron at heyaaron.com> 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 > > On Wed, Jul 24, 2019 at 11:47 AM Robert Simmons <rsimmons0 at gmail.com> > wrote: > >> I am and am not. Ubuntu has made this choice recently. I doubt I am alone >> in my thinking. I fully expected instant pushback on both suggestions. >> >> On Wed, Jul 24, 2019, 13:29 Luke Crooks <luke at solentwholesale.com> wrote: >> >> > Clearly you underestimate the technical debt for both hardware and >> > software technologies, still very much in use today. >> > >> > >> > >> > Luke Crooks >> > Solent Wholesale Carpets >> > >> > On Wed, 24 Jul 2019, 17:58 Robert Simmons, <rsimmons0 at gmail.com> wrote: >> > >> >> I wonder if FreeBSD should drop support for 32bit? Clean out and remove >> >> all >> >> of it. It should make the code base easier to maintain, cleaner, and >> >> safer. >> >> >> >> In this same vein, let's deprecate and remove things like telnet and >> ftp. >> >> _______________________________________________ >> >> freebsd-security at freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-security >> >> To unsubscribe, send any mail to " >> >> freebsd-security-unsubscribe at freebsd.org" >> >> >> > >> _______________________________________________ >> freebsd-security at freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to " >> freebsd-security-unsubscribe at freebsd.org" >> >
On Wed, Jul 24, 2019 at 12:09 PM Robert Simmons <rsimmons0 at gmail.com> wrote:> Yes, to reduce the code base complexity so that resources can be focused > on a smaller code base. >That seems like several completely different arguments. Codebase complexity, available resources, and "a smaller code base". So why does removing telnet and FTP solve or partially solve codebase complexity whereas removing sh or curl not solve the problem? As for available resources, is that currently a problem? Is there no telnet or FTP maintainer? Are they complaining they're overworked with a flood of changes to the telnet protocol (have there been any changes in the last 2 decades)? Why is "a smaller code base" a goal? Shouldn't it be more along the lines of "the smallest most efficient code base necessary to support feature x, use-case y, or project z"? I'm being a bit snarky with this, but you could solve all the problems you listed by distributing an OS that simply had an 'ls' command and that's it. No login. No vi. No video support. No nothing. It just boots to a prompt and allows you to type 'ls'. Much smaller codebase, less complexity, tons of resources for a very small project. Maybe I misunderstood based on Stephen's earlier reply though. If the case is simply removing it from the base to ports, I would have less of an issue. It means a bit more work on my end, but at least the functionality is available. I would think it would have a minor impact on users coming over from Windows, Linux, or other BSDs with the former two being less inclined to dive in and compile from source or even know/understand ports initially. -A
On July 24, 2019 12:09:12 PM PDT, Robert Simmons <rsimmons0 at gmail.com> 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 <aaron at heyaaron.com> >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 >> >> On Wed, Jul 24, 2019 at 11:47 AM Robert Simmons <rsimmons0 at gmail.com> >> wrote: >> >>> I am and am not. Ubuntu has made this choice recently. I doubt I am >alone >>> in my thinking. I fully expected instant pushback on both >suggestions. >>> >>> On Wed, Jul 24, 2019, 13:29 Luke Crooks <luke at solentwholesale.com> >wrote: >>> >>> > Clearly you underestimate the technical debt for both hardware and >>> > software technologies, still very much in use today. >>> > >>> > >>> > >>> > Luke Crooks >>> > Solent Wholesale Carpets >>> > >>> > On Wed, 24 Jul 2019, 17:58 Robert Simmons, <rsimmons0 at gmail.com> >wrote: >>> > >>> >> I wonder if FreeBSD should drop support for 32bit? Clean out and >remove >>> >> all >>> >> of it. It should make the code base easier to maintain, cleaner, >and >>> >> safer. >>> >> >>> >> In this same vein, let's deprecate and remove things like telnet >and >>> ftp. >>> >> _______________________________________________ >>> >> freebsd-security at freebsd.org mailing list >>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-security >>> >> To unsubscribe, send any mail to " >>> >> freebsd-security-unsubscribe at freebsd.org" >>> >> >>> > >>> _______________________________________________ >>> freebsd-security at freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-security >>> To unsubscribe, send any mail to " >>> freebsd-security-unsubscribe at freebsd.org" >>> >> >_______________________________________________ >freebsd-security at freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-security >To unsubscribe, send any mail to >"freebsd-security-unsubscribe at freebsd.org"This reminds me of a discussion I had with a manager at a company I developed IBM mainframe software at. His point was this exactly, in order to reduce expenses through the reduction of staff. Given the "staff" on the FreeBSD project are all volunteers, the vast majority of which work on projects/code of our choosing, I don't see your point. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert <Cy.Schubert at cschubert.com> FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
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.