Re: FreeBSD 14: Poll armv6 deprecated or removed
- In reply to: tech-lists : "Re: FreeBSD 14: Poll armv6 deprecated or removed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 04 Nov 2021 18:53:18 UTC
On 2021-Nov-4, at 07:50, tech-lists <firstname.lastname@example.org> wrote: > On Wed, Nov 03, 2021 at 09:52:19AM -0700, Kevin Bowling wrote: > >> FreeBSD wants any audience to help support the features they demand. Since >> this particular audience has not, what may cause it to in the future? Not a >> rhetorical question nor a vote for removing, this is a perennial problem in >> open source and I am curious how you think this works so I can incorporate >> it into my opinion. > > Maybe the audience isn't demanding? It doesn't mean the audience isn't > there. perl and python and shell scripting work fine on these boards. Issues with these things would I guess be taken up with those maintainers. The hardware is very stable. I'd expect that a lot more users might pipe up if their freebsd os needed updating for some newer python only to find it couldn't be updated anymore. The first of those to pipe up i'd guess be those with boards that have an internet-facing connection, as the pressure to keep fully updated is a lot less within a firewalled LAN. > > OpenBSD immediately after install has an email on the system giving a > method to send in a dmesg. I don't know if it gives them a handle on the > number of users and what their hardware is, but it's better than nothing > at all, which is where FreeBSD is. Although there is a port called > sysutils/hw-probe, one needs to know about it first. It's not in base. > > For armv6 in particular though, I've not heard of any reason justifying > *why* getting rid of it. At least if it's in base we can compile ports > for it ourselves. mips/mips64 stopped because the working group stopped > working with it, fair enough. This isn't the case with armv6. [This note is in part because a prior note oof mine did not make it to freebsd-arch.] Without one or more developers willing to keep ARM11 based RPi* FreeBSD working as FreeBSD updates, the code will break. Other architectures have been removed for such. Folks that do not want to work on such code do not want to have to work on it to keep FreeBSD building and operating for other architectures that have active developmers/maintainers. If there were active FreeBSD developers for ARM11 RPi*'s, the removal would have been unlikely to be proposed at all, even if the use was minor. FreeBSD is driven by the developer context directly, not the usage context directly. The usage context only drives things when the that context pays for developers to support the usage. (Think companies that use FreeBSD in a way that involves being sure supporting development and/or maintenance is done for the variant(s) they use.) [FreeBSD for aarch64 RPi*'s seems likely to suffer the same fate at some point because RPi* specifics are involved: generic aarch64 code is not sufficient. The aarch64 tier 1 status does not imply a requirement to support aarch64 RPi*'s.] > It might be helpful looking from another viewpoint - why is armv6 a > tier1 architecture on NetBSD? Something like, say, aarch64 being tier 1 on FreeBSD does not imply support for all existing and future aarch64 systems. The same goes for armv6. The same is true of NetBSD. NetBSD supports a lot of systems that FreeBSD does not. That fact has never justified having support for those systems in FreeBSD. FreeBSD has previously removed support for things NetBSD still supports. Different developers, different criteria. NetBSD will always be likely to support far more systems than FreeBSD. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)