LWN: Comments on "Software and hardware obsolescence in the kernel"

Software and hardware obsolescence in the kernel

nybble41 — Wed, 14 Oct 2020 18:31:26 +0000

> So an 8-bit x86 processor could be called big-endian if it reads the MSB first?

Yes, the serialization of the word on the 8-bit bus would be accurately labeled big-endian if the MSB is transferred first—not that this would be observable to software. The storage would still be little-endian since the LSB is stored at the lowest-numbered address. This can be confirmed by accessing the same memory address with byte- and word-oriented instructions.

Software and hardware obsolescence in the kernel

immibis — Wed, 14 Oct 2020 10:50:16 +0000

So an 8-bit x86 processor could be called big-endian if it reads the MSB first?

I don't think so.

Software and hardware obsolescence in the kernel

set — Sun, 13 Sep 2020 04:04:24 +0000

For fun not to long ago I got a >20 year old dynamicly linked Mosaic binary to run on my modern linux box. The problems there were 1) finding and installing the old required libraries, which was fairly trivial. 2) Layouts and assumptions about userspace 20 years ago meant that even though the program ran, it did not function well because some things just were not where they were expected back then. Also the web has changed a bit;) If it were important the program ran correctly, I would have used a vm with some old distribution in it.

Software and hardware obsolescence in the kernel

nix — Fri, 11 Sep 2020 19:40:25 +0000

I did something similar when adding mixed-endianness support to binutils libctf (excluding the ctf_archive format, which predated this idea and is always little-endian: I'll fix that in the next format rev). Cross-compilation notwithstanding, executables in general are usually read on architectures of the same endianness as the native endianness of the architecture they are generated on, so we write CTF dicts in the native endianness (historically, Solaris CTF did the same, presumably for the same reason). The only endianness-sensitivity is at open time, where we look at the dict's magic number to determine this dict's endianness, and endian-swap the whole dict in memory if the wrong endianness is detected.

This approach has two significant advantages over endian-flipping to a format-specified hardwired endianness: firstly, you never incur endian-flipping overhead in the common case of the same endianness being used on the generator and reader, no matter what the endianness of your machine; secondly, almost the entire codebase can completely ignore all this awful stuff, and only one localized place (the place that endian-flips if a foreign endianness is detected) needs to know about it.

The downside is that I need to explicitly test creating CTF on a machine with one endianness and then using it on one with the opposite endianness, or the endian-flipping code will never be exercised and will eventually silently rot. But still it seems to be much less bug-prone than forcing the format to be one specific endianness and compensating for that everywhere.

Software and hardware obsolescence in the kernel

nix — Fri, 11 Sep 2020 19:27:59 +0000

That looks like the opposite of PDP-endian.

(Still looking back in history, the VAX had even crazier endiannesses, particularly for its weirdo floating-point formats.)

Software and hardware obsolescence in the kernel

mjg59 — Fri, 11 Sep 2020 18:12:59 +0000

I've been working on a big endian system recently and I'm finding it surprisingly hard to parse register dumps having got so used to little endian.

Software and hardware obsolescence in the kernel

mpr22 — Fri, 11 Sep 2020 17:18:07 +0000

Debugging based on hex dumps is much nicer on big-endian archs than little-endian ones.

Of course, most people don't have to do that very often these days.

Software and hardware obsolescence in the kernel

rep_movsd — Fri, 11 Sep 2020 10:05:12 +0000

Little endian just makes more sense - simpler.

I never understood why someone would use an un-intuitive big endian format ( which is clearly based on the fact that we write numbers left to right manually )

Software and hardware obsolescence in the kernel

marcH — Sun, 06 Sep 2020 19:00:07 +0000

> https://thedailywtf.com/articles/The-Defect-Black-Market
> Besides the subtleties of making it work,...

If you don't mind cheating then it's much more valuable to sell defects _outside_ the company. Works for both testers and developers.

Spy agencies and criminals wouldn't be doing their work if they were not approaching "vulnerable" developers asking them to add some security "mistakes" in poorly reviewed and tested areas of the code. Easier to hide and deny with an unsafe language like C where intentional memory corruption mistakes are barely distinct from unintentional ones. Even more discreet in a project that does not separate security bugs from other bugs. The only thing difficult to hide is the check/reward.

> There's also developer preferences; most programmers want... Neither encourage companies...

I think management not studying and not questioning what "their programmers want" is a good indicator of "companies being clueless about development costs". "Rock Stars" programmers is of course the extreme version of that.

Software and hardware obsolescence in the kernel

dvdeug — Sun, 06 Sep 2020 01:43:36 +0000

> removing duplication or _unused_ code, no customer cares about that.

The second line of the article says:

>> Removing code that is no longer useful can be harder, mostly because it can be difficult to know when something is truly no longer needed.

> Same with validation: employees who find bugs before customers save their companies a lot of money and should be rewarded correspondingly. How often have you seen that happening?

https://thedailywtf.com/articles/The-Defect-Black-Market

Besides the subtleties of making it work, there's the questions of financial value. There's a certain point where getting something out today is much better than getting something slightly better out tomorrow, especially when tomorrow is going to bring new hardware you have to run on and thus new bugs.

> most companies are still clueless with respect to actual development costs.

I think that modern capitalism has made many companies worry about today and not tomorrow. Long-term thinking can be discouraged in these projects. There's also developer preferences; most programmers want to write the interesting new code, not spend a week trying to figure why these 10,000 lines of spaghetti code are returning a value that it obviously can't return. There's other developers who will refactor and refactor even when it produces more bugs and less clarity than they started with. Neither encourage companies to go back and clean up.

But I go back to my original comment; people will curse an OS that crashes once a day, but they won't use an OS that doesn't work on their system. Several times in business I've been told how to work about nasty bugs in specialized programs; maybe they got reported upstream, maybe not, but I was told e.g. to twiddle with business numbers until the report printed and then fix them in pen. The upstream is not clueless with the actual development costs in those cases; the users will curse it and work around the bugs, as long as it does what they need. Windows 95 may have sucked, but it was good enough the users tended to stick around despite the bugs.

Software and hardware obsolescence in the kernel

marcH — Fri, 04 Sep 2020 17:07:46 +0000

> An industry is going to value what sells.

Sure but I was writing about something entirely different: removing duplication or _unused_ code, no customer cares about that. This saves maintenance costs and makes adding new features easier yet good luck "selling" this to your average manager in your annual review. I don't know who is Arnd's manager but he seems like a lucky guy ;-)

Same with validation: employees who find bugs before customers save their companies a lot of money and should be rewarded correspondingly. How often have you seen that happening?

There's generally no tracking of who adds the most bugs either. If they really meant business, companies would have a "guilty" field in bug trackers. It wouldn't be rocket science thanks to "git blame" (the command name is a good start...) but I guess "creators" who add new code and bugs are too venerated for that to ever happen. We even have "rock stars", says a lot.

I heard a rumour that Apple is... different in that respect. It seems to achieve some results wrt. to quality.

tl;dr: most companies are still clueless with respect to actual development costs.

Software and hardware obsolescence in the kernel

dvdeug — Fri, 04 Sep 2020 09:45:57 +0000

> It's sad the industry seem to still value new code more than deleted code, should be the other way around.

An industry is going to value what sells.

Maybe Minix really is a super-reliable system with crystal clear code. Does it run on x86-64? No. Does it run on ARM64? No. Does it run on a Raspberry Pi? No. So I have a super-reliable system I can run in an emulator in a system that valued working over elegance.

For another example, "I just downloaded a file and opened it up" beats "I just downloaded a file and turns out to be TIFF with CCITT T.6 bi-level encoding or a PCX file or use a Microsoft MPEG-4 Version 3 video codec" and I have to dig up code that works (who cares if it's elegant) or give up on viewing it.

There are points when stuff should just go. But if you rewrite Linux filesystem code so it supports ext4 and iso9660 and drops support for all those obsolete and half-supported filesystems like NTFS and JFS and hpfs and VFAT, I don't see why anyone not a kernel programmer should consider that an improvement, even if it did get 0.7% faster. And even among kernel programmers, it seems they're the most likely to have a partition for other operating systems and old drives and disks around with non-ext4 filesystems.

I believe Linus also talks about not breaking code that runs on Linux. It's easy to delete obsolete features if you don't care about code that wasn't updated yesterday.

Software and hardware obsolescence in the kernel

geert — Fri, 04 Sep 2020 08:39:00 +0000

The R82 is in-order, so more predictability.
Still, it has branch prediction, so less predictability.

Software and hardware obsolescence in the kernel

pm215 — Thu, 03 Sep 2020 19:47:50 +0000

The R82's MMU bit is optional (per the blog post), so ARMv8R AArch64 doesn't imply an MMU inherently. It just means it's v8, it's R-profile (ie primarily MPU) and it's running 64-bit.

If you'd prefer a different definition, Peter Greenhaugh is in the anandtech comments on https://www.anandtech.com/show/16056/arm-announces-cortex... defining Cortex-R as being all about low interrupt latency, tightly-coupled memory and the like. (Low-and-predictable latency has always been why the MPU.)

Software and hardware obsolescence in the kernel

geert — Thu, 03 Sep 2020 17:44:01 +0000

Indeed, originally the big-endian Linux ports used the unmodified ext2 file system, leading to incompatible metadata layout with little-endian machines.

When people realized the incompatibility, two options were considered:
1. Add non-natitve endian support to ext2, i.e. do byteswapping when needed, protected by a config option,
2. Declare ext2 to be little-endian, and provide an option to migrate the big-endian format to little-endian.
Option 2 was picked, as 1 (when enabled) incurred a high runtime cost due to the conditional byteswapping code, and 2 turned out not that much slower than 1 (when disabled), due to the compiler doing a quite good job in optimizing the code.
After a while, all big-endian ext2 file systems had been migrated, and e2fsck no longer needed the -s option.
Similarly, XFS was declared to be big-endian, as it originated on big-endian SGI machines.

Software and hardware obsolescence in the kernel

mchouque — Thu, 03 Sep 2020 15:49:13 +0000

ext2 used to be like that IIRC...

You couldn't mount a filesystem coming from a BE on a LE machine and vice-versa.

e2fsck used to have an option for that:
-s This option will byte-swap the filesystem so that it is using
the normalized, standard byte-order (which is i386 or little
endian). If the filesystem is already in the standard byte-
order, e2fsck will take no action.

-S This option will byte-swap the filesystem, regardless of its
current byte-order.

Software and hardware obsolescence in the kernel

excors — Thu, 03 Sep 2020 15:37:02 +0000

Hmph, it's not fair when ARM changes the definition of ARMv8-R to make me look wrong :-) . The ARMv8 ARM (https://developer.arm.com/documentation/ddi0487/fc/) explicitly says the A profile "Supports the A64, A32, and T32 instruction sets", the R profile "Supports the A32 and T32 instruction sets", and the M profile "Supports a variant of the T32 instruction set", so (according to that documentation) 64-bit is exclusively for A. The Cortex-R82 must be a new, as-yet-undocumented profile.

Some of the existing documentation actually refers to the "ARMv8-R AArch32 architecture profile", and the Cortex-R82 is called "ARMv8-R AArch64", so it looks like that's how they're distinguishing it. The term "ARMv8-R" is now ambiguous and can refer to two very different architectures (one with an MMU, one without).

Software and hardware obsolescence in the kernel

pm215 — Thu, 03 Sep 2020 13:51:10 +0000

Also, just announced, a 64-bit R-profile core:
https://community.arm.com/iot/b/internet-of-things/posts/...

So "A-profile means 64 bit" is now wrong from the other direction too :-)

Software and hardware obsolescence in the kernel

nybble41 — Wed, 02 Sep 2020 03:51:01 +0000

> Natural languages are all about context, that's why computers need Unicode bidi = a bit more help.

Indeed, natural language is all about context. I get the feeling that we are talking about two completely different things and getting frustrated because the other person's answers make no sense in the context of what we each thought the conversation was about. I have been trying to describe how the terms "big-endian" or "little-endian" would apply to the *visual* layout of Arabic numerals *at rest*, for example as symbols written on paper—akin to the individual bytes of an integer field which is part of a larger structure stored in RAM or a file on disk. You seem to be interpreting my statements in the context of data which is *being* written, or read, or typed into a computer—a *serialization* of the data. Or perhaps you are referring to the particular way that the digits would be serialized as Unicode code points in a text file. Naturally my statements would seem like nonsense when taken that way; they were not intended for that context.

For data at rest there is no "time" component; all that matters is the relationships between the addresses or coordinates where each of the digits is stored. For digits written in a single line on paper this corresponds to linear physical coordinates; a digit may appear either to the left or the right of another symbol. In terms of the analogy to the storage of an array of multi-byte integers in computer memory, a system in which the most-significant digit of each number in a list of numbers is physically located on the same side as the first element of the list is "big-endian" and a system in which the least-significant digit is physically closest to the first element of the list is "little-endian". Any given serialization of the data (the process of reading or writing, for example) may employ a different "endianness" independent of the visual layout, and indeed that is the case for Arabic numerals: they are stored or rendered (on paper or other visual medium) as little-endian, but read, written, typed, or spoken aloud with the most significant digit first, in big-endian format.

Anyway, this debate is almost as pointless as the fictional conflict from which we get the terms "big-endian" and "little-endian".[1] I only replied in hopes of conveying that we are arguing *past* each other more than we are actually disagreeing about anything of substance.

[1] https://www.ling.upenn.edu/courses/Spring_2003/ling538/Le...

Software and hardware obsolescence in the kernel

marcH — Tue, 01 Sep 2020 16:28:37 +0000

> Are you being deliberately obtuse?

I thought you were.

Natural languages are all about context, that's why computers need Unicode bidi = a bit more help. This has been well discussed and explained in several other places in this thread (thanks to all those who did) but if not obtuse you are definitely not receptive. Never mind.

Software and hardware obsolescence in the kernel

atnot — Tue, 01 Sep 2020 15:10:33 +0000

I think there's an important caveat here in that you are talking about *binary* compatability. IME you can compile most software from decades ago today and it will run fine. I think this model of software compatibility is more desirable and I'm not sad about it for the same reason as I'm not sad the kernel doesn't make an effort to have a stable abi. I don't think anyone in FOSS should be spending extra effort just to make things right for a bunch of corporations that refuse to return the favor.

Software and hardware obsolescence in the kernel

nybble41 — Tue, 01 Sep 2020 15:01:42 +0000

> Of course they can, that's called "reading". I can hardly believe you wrote this...

Are you being deliberately obtuse? If I sent you a picture of some digits I wrote left-to-right and some digits I wrote right-to-left, "reading" is not going to be enough to tell them apart. Here, I'll demonstrate:

1234
1234

To simulate physical writing I filled both lines with spaces and then overwrote the spaces with digits. One line was filled in left-to-right, and the other line right-to-left. Please tell me, which one was written left-to-right?

Software and hardware obsolescence in the kernel

farnz — Tue, 01 Sep 2020 09:31:50 +0000

Back in the day, you ran the applications that currently use A7 cores on 8051s and similar chips. To a very large extent, this is all a balancing act; if 64 bit cores become cheaper than 32 bit, then hardware will move to 64 bit cores, even though an 8 bit core is plenty.

After all, lots of devices are moving to 32 bit ARM v7-M cores, even though an 8051 is still plenty when you have 2k RAM and 16k Flash, because a 32 bit ARM is nicer to develop for, and the sheer volume of ARM cores means it's now cheaper to buy an ARM device than an 8051.

Software and hardware obsolescence in the kernel

tdz — Tue, 01 Sep 2020 08:48:03 +0000

Another point when considering code obsolescence is how easy it is for someone to pickup the hardware and try to use it. The discussion focuses on computer architectures, which tend to remain dead after they reached their EOL. But old add-on cards and USB devices are often easy to use on modern systems. Removing the rsp drivers would be a mistake, even if the hardware is not in widespread use anymore.

Software and hardware obsolescence in the kernel

marcH — Tue, 01 Sep 2020 01:23:23 +0000

> The order in which you wrote the digits is not part of the written record. Someone coming along later can't even tell what order the digits were recorded in

Of course they can, that's called "reading". I can hardly believe you wrote this...

Computers are not as smart though, so they may need some additional clues: https://www.w3.org/International/articles/inline-bidi-mar...

Software and hardware obsolescence in the kernel

notriddle — Tue, 01 Sep 2020 00:43:18 +0000

August 31, 2020 at 12:00 PM

Figure out the endianness of THAT notation!

Software and hardware obsolescence in the kernel

kjpye — Mon, 31 Aug 2020 23:23:37 +0000

Actually, everybody reads numbers in a zig-zag fashion.

If you are reading a number like 8034175, you start "eight million", but you can't get past the "eight" until you have scanned from the right of the number to the left to determine the magnitude.

So a non-Arabic speaker will read left to right, encounter the number and skip to the end of the number and scan back to determine the magnitude and then read the number left to right and continue reading towards the right.

An Arabic speaker will encounter the right-hand end of the number first, scan across it to determine the magnitude and then read the number left to right. Then they will jump back to the left of the number and continue reading towards the left.

The only real difference is in whether the jump occurs before reading the number (non-Arabic) or after (Arabic).

Software and hardware obsolescence in the kernel

willy — Mon, 31 Aug 2020 22:23:59 +0000

There's a register in PA-RISC that reports the "bit number" of something. On 32-bit system, we respond by clearing 1 << (31-x). On 64-bit systems, we clear 1 << (63-x).

The disease metastatized outside of IBM.

I'm surprised nobody's yet mentioned the mixed endian ARM FPU system (maybe it's too old) where the bytes in each 32-bit word were stored little endian (as befitted the LE architecture that ARM was at the time), but the words were stored in the wrong order. ie 45670123

Software and hardware obsolescence in the kernel

nybble41 — Mon, 31 Aug 2020 22:22:00 +0000

> No because the numbers are not part of the text, they're a left-to-right insert in a right-to-left text.

> As explained here, Arabic speakers start with the most significant digit when they read and write just like everyone else and that it is what should define what the "lowest address" is…

It doesn't make sense to talk about big-endian or little-endian without a single, consistent frame of reference for the addressing which is independent of the content. In a context where you would write the elements of a list right-to-left, that means starting with the lowest address on the right and monotonically increasing toward the left. Only after having defined this addressing scheme can we venture to answer whether the components of the list are written big-endian or little-endian with respect to that surrounding context.

The digit you read or write first (temporally, not spatially) has nothing to do with endianness. The order in which you wrote the digits is not part of the written record. Someone coming along later can't even tell what order the digits were recorded in; it makes no difference to them whether you wrote the least- or most-significant digit first. All they can see is the order of the digits as they are laid out visually on the page.

In serial communication the standard is different. There it matters which digit is pronounced first, because the temporal order of the symbols is *all* you can observe.

Software and hardware obsolescence in the kernel

nybble41 — Mon, 31 Aug 2020 21:44:39 +0000

It depends on what you're doing. 64-bit addition and subtraction are generally plenty fast enough on 32-bit systems. Left or right shift (except by a constant 32 bits) requires a few more operations, and may get turned into a library call if the shift amount varies. 64x64 multiplication takes a bit more effort (three 32x32 multiplies and two additions) but will still generally be emitted inline. The real problem area is division (or modulus), which typically requires a call to libgcc or libcompiler-rt. The software to emulate unsigned 64-bit division on 32-bit x86 hardware runs to about 90 lines of optimized assembly code. The generic version[2] is about 170 lines of C. (Note: The generic version of __udivdi3 is implemented in terms of __udivmoddi4.)

In my own extremely informal benchmarks, a series of 100M 64-bit divisions took about 40% longer to complete when compiled as a 32-bit x86 binary vs. the same code compiled for amd64. Both versions were run on the same 64-bit CPU and compiled with clang-9 -O2.

[1] https://github.com/llvm-mirror/compiler-rt/blob/master/li...
[2] https://github.com/llvm-mirror/compiler-rt/blob/master/li...

Software and hardware obsolescence in the kernel

marcH — Mon, 31 Aug 2020 21:22:30 +0000

> The least-significant digit is located at the lowest address, closest to the beginning of the text.

No because the numbers are not part of the text, they're a left-to-right insert in a right-to-left text. There are effectively two "address spaces" embedded in one another (a.k.a. "zig-zag").

As explained here, Arabic speakers start with the most significant digit when they read and write just like everyone else and that it is what should define what the "lowest address" is, otherwise non-Arabic speakers are misled into thinking Arabic speakers do something different which is exactly what happened in this thread. Speech readers would be confused too.

Software and hardware obsolescence in the kernel

nybble41 — Mon, 31 Aug 2020 20:53:52 +0000

> So in conclusion, numbers are *written* in big-endian direction in all common scripts, and probably read in that direction too, but this may be the opposite direction to the normal one.

They're read big-endian but written little-endian. Endianness is determined by the position (address) of each digit, not temporal order in which they're written. The least-significant digit is located at the lowest address, closest to the beginning of the text. When "serialized" (read aloud or subvocalized) the numbers are converted into big-endian format, with the most significant digit spoken first.

Software and hardware obsolescence in the kernel

nybble41 — Mon, 31 Aug 2020 20:46:11 +0000

> Native Arabic readers don't start reading the lowest-magnitude digit first, they skip to the largest digit and read left-to-right. Both when reading, and when uttering the number….

So numbers are written in little-endian notation (given right-to-left addressing for "unstructured" data, i.e. plain text), and converted to big-endian when "serialized" (spoken aloud) without rearranging the rest of the text. That sounds exactly like a traditional little-endian network stack to me.

Software and hardware obsolescence in the kernel

smoogen — Mon, 31 Aug 2020 18:08:42 +0000

Making chips with a specific bit size has a cost involved in that the physical space used for that manufacturing can't be used for something else. Also while the main blue-print may not need to change, you can only use the 'chip' dies for a certain amount before putting together new parts for it. Each time that happens it means you have to recertify the chip matches what was originally built. If you decide that you are going to put together a 10nm chip instead of the 30 nm 32 bit you had from a long time ago.. it is a completely new design. That takes costs and it also has a risk of failure and dealing with again a whole line of equipment being used for a specific low build chip.

Instead it is a lot 'cheaper' in manufacturing to come up with a 64 or 128 bit chip you can use across lines and maybe stick some stuff in front which makes it act like its 8bit or 32 bit ancestor. That means you can shrink the amount of factory space you need which cuts costs.

Software and hardware obsolescence in the kernel

marcH — Mon, 31 Aug 2020 17:11:31 +0000

> Yikes!

This zig-zag doesn't feel like a very hard hand writing challenge, I mean not unless you have to deal with crazy long numbers. For computers and terminals it's apparently a bit harder :-)

> I guess that’s one concrete reason why left-to-right scripts are superior (apart from ink smudging).

Ink smudging _and_ hiding what you just wrote. Look at how left-handed people tend to bend their wrist, even with a pencil.

My urban legend is that right-to-left languages were superior for... carving. Ten commandments and all that :-)

Software and hardware obsolescence in the kernel

geert — Mon, 31 Aug 2020 12:09:46 +0000

No idea. I hope until a version that includes proper y2038 support ;-)

Software and hardware obsolescence in the kernel

arnd — Mon, 31 Aug 2020 11:46:00 +0000

Any guess how long they plan to update kernels though?

If they are already on older software releases, updating to modern kernel and glibc is already going to be tricky, and getting worse as time passes. I hope we can still update a lot of the Armv7 systems that are already deployed

Incidentally it seems that the last CPU used on MVME cards (64-bit QorIQ P5020) is at the end of its 10 year expected life, but support for that generation never made it upstream. The 2019 manual for the previous generation (32-bit MVME7100/MPC8641D) lists Linux-2.6.25 as the default, with Linux-2.4 still an option for older machines "beyond 2020".
https://github.com/voltumna-linux/meta-artesyn/blob/maste... on the other hand does have updates for modern kernels.

Software and hardware obsolescence in the kernel

pm215 — Mon, 31 Aug 2020 09:42:45 +0000

QEMU used to use the _fast_ integer types in some places (notably the floating point emulation code). We switched to using the exact-width types, because in practice almost all of our supported host systems used the same choice of underlying size for the fast-types, and we didn't want to find ourselves running into "code works fine on almost all systems including the ones it was developed and tested on and that 99% of the dev community use, but breaks on the less-common platform that defines the size of one of these types differently" bugs -- we preferred "same behaviour on all platforms". (IIRC one of the BSDs made slightly different choices, maybe for the 16-bit fast type.)

Software and hardware obsolescence in the kernel

geert — Mon, 31 Aug 2020 09:18:11 +0000

Probably far beyond y2038...

A few years ago, someone who worked for the Australian navy told me that, given how low they kept running m68k MVME boxes, he expected the "new" PPC MVME boxes to keep running beyond y2038. So yes, "modern" 32-bit ARM should easily surpass that.

Software and hardware obsolescence in the kernel

jem — Mon, 31 Aug 2020 08:21:52 +0000

Not all all devices need to consume forever growing hardware resources. And if some do, new applications will spring up below that are quite happy with, say, 256 MB of RAM and a 200 MHz 32-bit CPU. For some use cases a capable A/D converter is more important than a GPU or gigabit networking. There is a myriad of chips on the market with 32-bit ARM A7 cores fully capable of running Linux. Back in the day you could boot the Linux kernel on a PC with only a few megabytes of RAM.