[HN Gopher] Future of 32-bit platform support in FreeBSD
___________________________________________________________________
Future of 32-bit platform support in FreeBSD
Author : PaulHoule
Score : 111 points
Date : 2024-02-20 11:26 UTC (11 hours ago)
(HTM) web link (lists.freebsd.org)
(TXT) w3m dump (lists.freebsd.org)
| rwmj wrote:
| Fedora has been slowly removing i686:
| https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Ke...
| https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemo...
|
| There's still some 32 bit software (usually proprietary stuff,
| and/or libraries used by Wine). Removing 32 bit libraries
| especially just breaks this software and you don't really have
| any option except to get the vendor to fix it.
|
| But more importantly I sometimes find 64 bit assumptions in code.
| One recent example was in this new package that we're trying to
| add to Fedora:
| https://bugzilla.redhat.com/show_bug.cgi?id=2263333 It doesn't
| compile on i686 with some obvious compile issues. Upstream isn't
| particularly interested in fixing them.
|
| Typically the issues are incorrect assumptions about the size of
| 'long' and 'size_t'. And incorrect casts from pointers to longs
| (instead of using uintptr_t).
|
| Does any of this matter still or should we embrace this 64 bit
| only world? Will CPU makers remove i686 support? I guess we're
| going to find out.
| CJefferson wrote:
| It's increasingly hard to test 32 bits -- I run a modern
| Ubuntu, they don't even provide 32 bits versions of most
| libraries any more, so I have to wonder why it's worth putting
| significant hours I to supporting 32bits, when it's unclear if
| there are even any users.
| rwmj wrote:
| I keep a very old Fedora VM around for this. Not ideal.
| torstenvl wrote:
| How about effort to remove undefined behavior based on non-
| portable assumptions?
|
| No code should cast a pointer to a `long`, ever. Trying to
| excuse it it with "we don't support 32-bit" is deeply wrong.
|
| EDIT: Apparently this position is unpopular. I am curious why
| people feel differently.
| CJefferson wrote:
| Well, yes, I'd like to do that, but programmers make
| mistakes and it isn't easy to test.
|
| Also, you can't reasonably remove all undefined behaviour.
| In C++ you basically can't do file IO without undefined
| behaviour.
| knorker wrote:
| As a fellow UB nitpicker, I'd like to hear more about
| your favorite UB triggers. E.g. in the space of file IO.
| mark_undoio wrote:
| On GCC , as far as I know, pointers will always cast to
| long and back ok. I'd expect the same from clang.
|
| No, that's not a portable behaviour but I can see that it's
| valid if you're targeting Linux.
|
| uintptr_t is more polite, though.
| a1o wrote:
| I agree with you, we have appropriate types now, so we
| don't need to use long anymore - long also has different
| assumptions in Windows x64 builds vs equivalent regular
| Linux x64 (see also LLP64 vs LP64 vs ILP64)
| Brian_K_White wrote:
| This is simply correct and I see no excuse for objecting.
|
| Hell I still try to make sure stuff works on both big and
| little endian.
| cesarb wrote:
| > No code should cast a pointer to a `long`, ever. Trying
| to excuse it it with "we don't support 32-bit" is deeply
| wrong.
|
| It's deeply wrong as an excuse but for a different reason:
| casting a pointer to long also works on 32-bit. The only
| mainstream architecture in which it doesn't work is 64-bit
| Windows.
| DinoCoder99 wrote:
| Sure, but just because something works doesn't mean you
| should do it. Better types have been around for what 25
| years now?
| electroly wrote:
| Does it matter to remove portability to platforms we don't
| care about any more? It's a question with no
| objectively/universally right or wrong answer. The obvious
| counterpoint I'd mention is big endian: is it worth fixing
| your endianness bugs? Or is it ok to assume little endian
| since the vast (VAST) majority of software does not care
| about the very few remaining big endian platforms? 32-bit
| could become a similar situation. It happened with 16-bit,
| right? Nobody today cares whether their modern code is
| portable to 16-bit machines.
|
| More generally, I disagree with absolutist takes on
| programming. There's no right or wrong in programming.
| There's just requirements and choices.
| int_19h wrote:
| Casting a pointer to long is incorrect on any LLP64
| platform, which includes all modern versions of Windows.
| ndiddy wrote:
| Ubuntu dropped 32-bit support several years ago. AFAIK they
| only support the 32-bit libraries required by Steam and Wine.
| jsheard wrote:
| > Does any of this matter still or should we embrace this 64
| bit only world? Will CPU makers remove i686 support? I guess
| we're going to find out.
|
| We're already on this path, Intel has proposed an "X86-S"
| subset which drops support for booting into 16/32-bit modes
| (though 32-bit applications would still be supported under a
| 64-bit OS), ARM Cortex-A cores already dropped support for
| 32-bit boot a few years ago and the latest ones are also
| dropping support for 32-bit applications, so the whole stack
| has to be 64-bit. Apple preemptively killed 32-bit apps even on
| hardware that could technically still support them, and their
| current hardware doesn't support 32-bit at all, not even in
| Rosetta.
| my123 wrote:
| Rosetta supports 32-bit code execution via a very basic
| (segment-level) facility, designed for use by Wine.
| jsheard wrote:
| TIL. I'm surprised they went out of their way to accomodate
| emulating 32-bit Windows apps, when they cut off 32-bit Mac
| apps completely.
| plorkyeran wrote:
| Dropping 32-bit macOS apps let them drop the second copy
| of every system library, and possibly even more
| importantly, support for the old obj-c runtime that was
| weird and different from the runtime used on every other
| platform. Supporting 32-bit wine is a much smaller
| burden.
| MBCook wrote:
| Which is especially useful on phones that are much more
| memory constrained than desktops.
| zahllos wrote:
| For the modern server/desktop and even laptop, that's also no
| bad thing. It is somewhat ridiculous that UEFI bioses,
| internally, still boot in 16-bit real mode and have to do all
| the steps your bios bootloader used to do to set up a 64-bit
| environment ready to go: https://github.com/tianocore/edk2/bl
| ob/edc6681206c1a8791981a..., https://github.com/tianocore/edk
| 2/blob/edc6681206c1a8791981a..., https://github.com/tianocore
| /edk2/blob/edc6681206c1a8791981a...
|
| Why not just start the CPU in "long mode", which is what
| everyone is using it for, in the first place?
|
| These newer ARM processors support 32-bit code at EL0 only
| (userspace). That seems like a reasonable approach for x86 as
| well and the freebsd announcement has this to say:
|
| > There is currently no plan to remove support for 32-bit
| binaries on 64-bit kernels.
|
| So for the moment, you can run 32-bit applications just fine.
| jsheard wrote:
| > These newer ARM processors support 32-bit code at EL0
| only (userspace).
|
| Even that is being phased out, starting from 2021 ARMs
| reference cores _mostly_ dropped 32-bit support, with the
| Cortex-X2 big cores and Cortex-A510 small cores being
| 64-bit only, and only the medium Cortex-A710 cores
| retaining the ability to run 32-bit code in userspace. With
| the next generation the medium cores lost 32-bit support,
| but the small cores gained 32-bit support again, so the
| chips can _barely_ still run 32-bit code but it 's
| relegated to only running on the least performant cores.
| I'm sure they'll drop it altogether as soon as they think
| the market will accept it.
| ksec wrote:
| I think we need to be more specific, since on x86 64bit
| instructions are a superset of 32bit. On ARM they are
| different with AArch32 and AArch64 being two separate set
| of instructions. It is AArch32 that is being dropped and
| no longer required.
| legulere wrote:
| They're mostly a superset, but also some instructions
| were dropped like the bcd opcodes.
|
| https://en.m.wikipedia.org/wiki/Intel_BCD_opcodes
| arp242 wrote:
| > Why not just start the CPU in "long mode", which is what
| everyone is using it for, in the first place?
|
| Are you sure it's "everyone"? No doubt it's "overwhelming
| majority", but that's not the same, and "everyone" is a lot
| of people.
|
| As I understand how this works, the compatibility is
| perhaps slightly inconvenient to a small group of
| developers, but not _that_ inconvenient and generally
| relatively cheap. So why not have and keep it?
|
| ARM has a lot less history than x86. Yes, it goes back to
| 1985 in the BBC Micro, but didn't really see serious usage
| as a "generic platform" until the late 90s/early 2000s.
| zahllos wrote:
| Do you ever boot your machine only into 32-bit mode? Most
| UEFI firmware I've seen is launching
| /EFI/BOOT/BOOTX64.EFI, which means your bootloader is in
| long mode even if you then switch back to 32-bit mode
| (and UEFI is likely already there). I don't know if
| emulating a traditional bios avoids this or not, never
| thought about it. But I'd take a guess that the vast
| majority of people are passing through long mode and then
| back again if they installed a 32-bit OS.
|
| I'm not saying remove the possibility of 32-bit
| _userspace_ and nor are, it seems, freebsd. I am saying
| don 't bother with a 32-bit kernel. Otherwise you're
| limited to a 4GB address space and hacks like PAE. No
| harm in running 32-bit binaries if you want and, I think
| Solaris actually left userspace as 32-bit only even on
| their 64-bit OS, unless the application really benefited
| from a 64-bit setup. Not sure what they do now, been a
| while since I used it.
|
| It's arguable ASLR only works well in a 64-bit mode, as
| well.
| arp242 wrote:
| > Do you ever boot your machine only into 32-bit mode?
|
| No, but I'm not everyone.
|
| Or let me put it this way: I don't know the motivation
| for why the things work like they do. It's entirely
| possible there is no good reason at all. Or maybe there
| is? Either way, I wouldn't assume anything so quickly.
| plorkyeran wrote:
| Intel is currently trying to find out if it's everyone.
| The whole point of announcing the idea of dropping the
| old modes years before you plan to actually do so is to
| give a chance for people to speak up if it's a problem.
| zokier wrote:
| > Why not just start the CPU in "long mode", which is what
| everyone is using it for, in the first place?
|
| Why not indeed?
|
| https://www.intel.com/content/www/us/en/developer/articles/
| t...
| judge2020 wrote:
| > Apple preemptively killed 32-bit apps even on hardware that
| could technically still support them, and their current
| hardware doesn't support 32-bit at all, not even in Rosetta.
|
| Slightly related: visionOS references "iOS" for old 32-bit
| apps when you view them on the App Store.
| https://rr.judge.sh/Acaciarat%2FIMG_0002.PNG
| dooglius wrote:
| I thought the Linux kernel enforces/requires a pointer to fit
| into a long, so any platform with Linux will define long type
| as appropriately sized?
| DinoCoder99 wrote:
| I'd much prefer C users not use long at all. What's wrong
| with size_t and uint32_t and uint64_t?
| UncleEntity wrote:
| > What's wrong with size_t and uint32_t and uint64_t?
|
| An extra #include and more typing?
|
| Plus, all the C89 users are out of luck...
| int_19h wrote:
| It's trivial to roll your own basic <stdint.h> with those
| types for existing C89 implementations.
|
| Unless they don't provide the corresponding type natively
| at all (which can be the case for some 16-bit platforms
| and 64-bit). But then you have a bigger problem anyway.
| legulere wrote:
| Only with effort Linux was able to be ported to Clang.
| All compilers that compile Linux should also be able to
| deal with size_t and consorts.
| cesarb wrote:
| > And incorrect casts from pointers to longs (instead of using
| uintptr_t).
|
| That's not an issue on mainstream Linux, since uintptr_t and
| long always have the same size, both on 32-bit and on 64-bit.
| It's an issue only when using some new experimental stuff which
| uses two machine words per pointer, or when trying to port to
| Windows (where long is always 32-bit even when compiling for
| 64-bit).
| Brian_K_White wrote:
| At one point 16 bits were universal, and then 32 bits came
| along and broke everything. We learned some lessons that day.
| Then 32 bits was universal for a while and 64 bits came along
| and broke everything. I guess we forgot those lessons, but OK
| well at least we learned them again for real this time.
|
| What a relief it is that we have reached the final
| architecture and will never have to worry about anything like
| that again!
| cesarb wrote:
| > At one point 16 bits were universal, and then 32 bits
| came along and broke everything.
|
| That's not an issue in mainstream Linux, since 16-bit Linux
| (ELKS) never caught on. Other than ELKS and perhaps some
| new experimental stuff, since its first release Linux
| always had long and pointer with the same size.
| arp242 wrote:
| At some point in history a "byte" could also be considered
| to mean any number of things. There was great value in
| standardizing on 8 bits.
|
| The there is of course no clean separation between the two,
| but by many definitions the "64-bit era" has already lasted
| longer than the "32-bit era". The _real_ lesson from
| history is that we moved for specific practical reasons,
| and that these reasons don 't exist with 64-bit
| architectures today. 64-bit is and most likely will remain
| the standard size for the foreseeable future. I predict
| that even embedded will (slowly) move to 64-bit because
| again, there is great value in standardizing these types of
| things.
| int_19h wrote:
| I agree that 64-bit is likely to be a very long-running
| standard. But, given that on 64-bit, there's no agreement
| on sizeof(long) - and it's impossible to change at this
| point because it would be a massive breaking ABI change
| for any of the relevant platforms - the only sensible
| standardization approach for C now is to deprecate
| short/int/long altogether and always use
| int16_t/int32_t/int64_t.
|
| It helps to look at the history of C integer type names
| and its context. Its origin lies not with C, but with
| ALGOL-68 - as the name implies, this is a language that
| was standardized in 1968, although the process began
| shortly after ALGOL-60 Report was published. That is, it
| hails from that very point in history when even 8-bit
| bytes weren't really standard yet nor even the most
| widespread - indeed, even the notion of storing numbers
| in _binary_ wasn 't standard (lots of things still used
| BCD as their native encoding!). ALGOL-60 only had a
| single integer type, but ALGOL-68 designers wanted to
| come up with a facility that could be adapted in a
| straightforward way to all those varied architectures. So
| they came up with a scheme they called "sizety", whereby
| you could append _any number_ of SHORT or LONG modifiers
| to INT and REAL in conformant code. Implementations could
| then use as many distinct sequences as they needed to
| express all of their native types, and beyond that adding
| more SHORT /LONG would simply be a no-op on that
| platform. K&R C (1978) adopted a simplified version of
| this, limiting it to a single "short" or "long" modifier.
|
| Obviously, this arrangement makes sense in a world where
| platforms vary so widely on one hand, and the very notion
| of "portable code" beyond basic numeric algorithms is
| still in its infancy. Much less so 40 years later,
| though, so the only reason why we still use this naming
| scheme is backwards-compatibility. Why use it for new
| code, then, when we had explicitly sized integer types
| since C99?
| arp242 wrote:
| Specifically on the topic of "avoid using long" I don't
| disagree; I was mostly replying to the general sentiment
| of "you should never assume 64 bit because this changed
| in the past and will change in the future". That said, if
| you're writing software specifically for Unix systems (as
| much software is) then it de-facto works, so it's fine.
| That's why people keep doing it: because it works in all
| cases where the software runs.
|
| Starting C in 2024 is like starting Game of Thrones in
| the middle of Season 5. Dubbed in Esperanto.
| int_19h wrote:
| More like dubbed in Volapuk. Dubbed in Esperanto would be
| Smalltalk.
| cesarb wrote:
| > There's still some 32 bit software (usually proprietary
| stuff, and/or libraries used by Wine).
|
| Wine is going to stop being an issue somewhat soon. The Wine
| developers are adapting it to work more like Windows, by making
| even 32-bit applications call the 64-bit libraries.
|
| I expect that, not long after Wine switches to always using
| 64-bit libraries, distributions (probably starting with faster-
| moving ones like Fedora) will completely (or almost completely,
| leaving only glibc and its dependencies) drop the 32-bit
| libraries. And we're already close to the Y2038 deadline, which
| gives distributions another incentive to drop 32-bit libraries
| (instead of having to go through a migration to the 64-bit time
| API, similar to the migration to 64-bit file offsets we had
| some time ago).
| zozbot234 wrote:
| Debian is moving their 32-bit releases to 64-bit time, it's a
| big transition but it's expected to be ready for the next
| release. But they've also announced that they may be forced
| to drop their i686 release quite soon.
| SomeoneFromCA wrote:
| Freebsd is sponsored by those who only in concerned about its
| server performance, and 32-bits are not there anymore.
| sitkack wrote:
| I am slightly concerned with running embedded Unix software if
| 32-bit is going away so fast.
| leonheld wrote:
| Why? We build everything from source anyway, and armhf
| compilers are not going away any time soon.
| jonhohle wrote:
| Building from source doesn't matter if platform support code
| is no longer in the OS source tree.
| adrian_b wrote:
| For open-source operating systems there will always remain the
| older stable 32-bit releases like FreeBSD 16 in this case.
|
| Even if there still are plenty of obsolete 32-bit CPUs running
| Linux or *BSD, since many years I have never seen a case where
| using them is the right technical choice.
|
| When a UNIX-like OS is desired, it is a mistake to use anything
| less than a very cheap 64-bit CPU, like one with ARM Cortex-A55
| cores.
|
| For the many embedded applications where a 32-bit CPU is
| appropriate, either one of the many open-source RTOSes should
| be used or a bare-metal program, which is the best choice in
| many cases. For such embedded applications, a UNIX-like OS is
| much too bloated and it does not allow deterministic control of
| the hardware.
| galangalalgol wrote:
| There os an in between space like the RPi zero where you can
| drop rt linux kernel (and rt modules). 32bit embedded linux
| is still really quite widespread. I expect risc-v to breath
| some new life into it as well. Sometimes a lack of hard (or
| any) real time requirements, combines with price and
| occasionally power (where I expect risc-v to come in) to
| allow for embedded linux. It usually requires less
| development time too. Think how many home routers, and
| security systems are still built off of 32bit linux. I don't
| know any built off of freebsd though, so maybe a good call?
| yjftsjthsd-h wrote:
| Actually I've been surprised at how much 64-bit dominates
| RISC-V even in the very lowest end of Linux-capable
| embedded. Perhaps I'm just in a bubble, though; not like I
| work in actual embedded stuff professionally.
| adrian_b wrote:
| The price difference between something with Cortex-A55
| 64-bit cores and something with obsolete 32-bit cores is
| negligible.
|
| For modern home routers or security appliances you want
| them to be able to easily execute firewalls with complex
| sets of rules at multi-gigabit per second throughput, so
| that the router throughput should not be limited by the CPU
| instead of the Ethernet or WiFi interfaces.
|
| For this, you really need something like Cortex-A55. The
| routers with obsolete CPUs limit the performance without
| any worthwhile price reduction.
|
| On the other hand, for many embedded projects where a
| 32-bit CPU is the right choice, the developers choose Linux
| just because they are familiar with it and they are too
| lazy to read the manuals of some free real-time operating
| system, even if in fact the latter might require less
| development work and maintenance work for their software
| project.
| pantalaimon wrote:
| The more bits you have to push around / the wider your
| registers and busses are, the more energy you are going
| to consume though.
| zokier wrote:
| Is that actually measurable difference on modern process
| nodes and cores as big as Cortex-A?
| zokier wrote:
| If even A55 is too chonky, there is also A34 which afaik
| is the smallest 64bit ARM core. Unfortunately I haven't
| seen anyone actually releasing chips based on it :(
|
| There are some socs with A35 cores though, that is
| probably lowest end that is actually available.
| pantalaimon wrote:
| FreeBSD was never big on embedded in the first place. 32 bit
| Linux isn't going to go away anytime soon.
| jandrese wrote:
| Lots of "fatter" embedded systems run on FreeBSD due to the
| more favorable license situation. Not so much SOHO routers,
| but big industrial routers will use it. Juniper is a
| notable example. But also 1U firewalls, SANs, etc... are
| often FreeBSD based.
| pantalaimon wrote:
| Well that's the tragedy of not contributing back upstream
| then. If there were companies actively maintaining the 32
| bit port, there would be no plans of dropping it.
| linksnapzz wrote:
| The companies use what their supply chain has, which ends
| up being 64-bit by default. They're not building their
| own 32-bit CPUs.
| emaste wrote:
| 32-bit x86 CPUs haven't been made in years, companies
| building products based on FreeBSD switched to 64-bit x86
| or to other architectures long ago. It's not that work on
| i386 is being done but kept in private repos and not
| upstreamed -- work on i386 just isn't being done at all.
| 0x457 wrote:
| Those aren't using x86 tho?
| justin66 wrote:
| Just a poor chose of words, I guess, but FreeBSD 16 will
| _not_ support 32-bit platforms.
|
| > For open-source operating systems there will always remain
| the older stable 32-bit releases like FreeBSD 16 in this
| case.
| UncleEntity wrote:
| > Even if there still are plenty of obsolete 32-bit CPUs
| running Linux or *BSD, since many years I have never seen a
| case where using them is the right technical choice.
|
| I have a couple WD NATs which chug along on 32-bit PowerPC, a
| patched kernel and the last version of Debian before they
| dropped support for 32-bit PowerPC. Don't really plan to
| replace them before they break...do need to work out a backup
| "story" (as the kids would say) but they just hold old TV
| shows so if they let out the magic smoke then nothing
| important is lost.
|
| Would be nice if I could keep them up to date on the latest
| and greatest but nobody cares about the 32-bits anymore...
| dark-star wrote:
| There will always be NetBSD which runs on everything from a
| potato to supercomputers, no matter how many bits of address-
| space it has ;-)
| sspiff wrote:
| While the porting of NETBSD used to be a meme, these days
| there are far more embedded platforms supported by Linux in
| some fashion.
|
| Sadly not all on the mainline, but having worked in the
| embedded world, Linux is a massive part of that space.
| int_19h wrote:
| I think it's reasonable to eventually treat 32-bit embedded
| in the same manner we treat 8-bit and 16-bit embedded
| today: as "weird" architectures that have their own bespoke
| OSes (even if it's a fork of Linux or BSD), and on which
| "normal" portable code is not really expected to compile or
| run without modifications.
| throw0101c wrote:
| Somewhat related:
|
| > _time_t is 8 bytes on all supported architectures except i386._
|
| * https://man.freebsd.org/cgi/man.cgi?arch
|
| * https://en.wikipedia.org/wiki/Year_2038_problem#Implemented_...
| jmclnx wrote:
| OpenBSD may be looking at the same:
|
| https://www.openbsd.org/i386.html
|
| Luckily NetBSD still exists, I very much doubt they will
| depreciate 32 bit:
|
| https://www.netbsd.org/ports/i386/hardware.html
|
| NetBSD to me is a cool system, doing some unique things. But,
| sadly they need more support than they get these days.
| SomeoneFromCA wrote:
| Yes NetBSD has nice chill vibe to it, neither Free nor Open
| has. But packages are less fresh, and lots of things are not
| supported.
| hiAndrewQuinn wrote:
| This is probably a good sign for anyone out there interested
| into getting into a long tail niche industry, similar to how
| COBOL lives on in banking. There are probably going to be
| places we'd never expect running 32-bit applications for
| decades to come (I'm thinking industrial automation shops and
| the like), and getting in on the ground floor of developing for
| NetBSD would be a high-powered signal that you are interested
| in helping support these ancient machines.
|
| (Do I recommend this myself? Well, I think techies find all
| kinds of weird things fun. :))
| accrual wrote:
| > OpenBSD may be looking at the same
|
| Is that in reference to this line?
|
| > Due to the increased usage of OpenBSD/amd64, as well as the
| age and practicality of most i386 hardware, only easy and
| critical security fixes are backported to i386. The project has
| more important things to focus on.
|
| This has been on the i386 page for quite a while. I haven't
| specifically heard of the developers dropping i386, but I also
| don't follow the mailing lists as much as I used to.
|
| I really hope OpenBSD doesn't drop i386 as it's my go-to
| operating system for a lot of otherwise not very useful
| hardware - retro PCs, 32-bit laptops, etc. One can take any bog
| standard Pentium or higher box and turn it into a usable
| machine with OpenBSD.
| tyfon wrote:
| Yeah, I'm still running openbsd on a dual pentium pro 200
| with 96 mb ram as my irssi machine :)
|
| It's almost a miracle that the quantum fireball in it still
| lives, it's over 20 years old now.
| accrual wrote:
| Very impressive setup! If the Fireball ever dies, an SSD or
| CF card will probably keep the rest of the box going for
| another 20 years. :)
| boring_twenties wrote:
| Why would you bother with the second CPU just for irssi?
| You would probably notice the energy savings from removing
| it
| tyfon wrote:
| I usually ssh into it, so sshd runs on one and irssi on
| the other. Also, the whole computer is just got fun.
|
| The motherboard also has a UW SCSI interface, but I have
| no disks left sadly. The 10k rpm Seagate died a long time
| ago.
| tcmart14 wrote:
| My understanding is that, they will support the architecture
| as long as one of the OpenBSD developers doesn't mind
| maintaining it. It isn't like Linux. Linux developers will
| make a top-down decision. OpenBSD is more of a, if a
| developer has the physical hardware and will to do it, it
| will remain supported until that is no longer true. Same with
| NetBSD, but I think NetBSD is a little more loose with the
| 'having physical hardware.' The spirit of OpenBSD is, no, you
| need to build on physical hardware. NetBSD doesn't mine the
| primary mechanism of testing and development being a QEMU
| image.
|
| Which hopefully gives some comfort. There isn't a shortage of
| cheap 32-bit x86 machines. The biggest problem are probably
| like sparc machines that getting your hands on one in _good_
| condition can still be pricey. But you can find a functional
| 32-bit x86 desktop machine on ebay for 30 bucks.
| kloch wrote:
| > Luckily NetBSD still exists, I very much doubt they will
| depreciate 32 bit:
|
| I love NetBSD and their focus ppears to be so you can run a
| modern supported/bugfixed OS on legacy hardware.
|
| So FreeBSD and NetBSD are perfect compliments to each other.
| asveikau wrote:
| Didn't OpenBSD keep platforms like VAX going for some time?
| Googling, they discontinued it in 2016, which is pretty late
| for that.
| riedel wrote:
| I guess it could eventually move to Tier II and join the 68k
| Amigas which is still on NetBSD 9.3 [0]
|
| [0] https://wiki.netbsd.org/ports/
| faefox wrote:
| This makes me feel old.
___________________________________________________________________
(page generated 2024-02-20 23:02 UTC)