Hacker News Reader

Comment by sitkack | Hacker News Reader

I am slightly concerned with running embedded Unix software if 32-bit is going away so fast.

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.

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?

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.

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.

The more bits you have to push around / the wider your registers and busses are, the more energy you are going to consume though.

Is that actually measurable difference on modern process nodes and cores as big as Cortex-A?

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.

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.

FreeBSD was never big on embedded in the first place. 32 bit Linux isn't going to go away anytime soon.

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.

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.

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.

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.

Those aren't using x86 tho?

> 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...

There will always be NetBSD which runs on everything from a potato to supercomputers, no matter how many bits of address-space it has ;-)

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.

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.

How many embedded 32-bit Unix softwares are being constantly upgraded to new versions of Linux / FreeBSD?

Why? We build everything from source anyway, and armhf compilers are not going away any time soon.

Building from source doesn’t matter if platform support code is no longer in the OS source tree.

Reply on news.ycombinator.com