Removing nommu feels wrong to me. Being able to run linux on a simple enough hardware that anybody sufficiently motivated could write an emulator for, help us, as individuals, remain in control. The more complex things are, the less freedom we have.
It's not a well argumented thought, just a nagging feeling.
Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings. A system that would allow communication, simple media processing and productivity.
These days it feels like we are at a tipping point for open computing. It feels like being a frog in hot water.
lproven 3 hours ago [-]
> Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings.
That was part of the plan for Minix 3.
Clean separation in a microkernel, simple enough for teaching students, but robust.
But Intel used it and gave nothing back, and AST retired. :-(
dragontamer 8 days ago [-]
I don't think software emulation is very important.
Let's look at the lowest end chip in the discussion. Almost certainly the SAM9x60.... it is a $5 ARMv5 MMU chip supporting DDR2/LPDDR/DDR3/LPDDR3/PSRAM, a variety of embedded RAM and 'old desktop RAM' and mobile RAM.
Yes it's 32-bit but at 600MHz and GBits of RAM support. But you can seriously mass produce a computer under $10 with the chip (so long as you support 4-layer PCBs that can breakout the 0.75mm pitch BGA). As in, the reference design with DDR2 RAM is a 4-layer design.
There are a few Rockchips and such that are (rather large) TQFP that are arguably easier. But since DDR RAM is BGA I think it's safe to assume BGA level PCB layout as a point of simplicity.
---------
Everything smaller than this category of 32-bit / ARMv5 chips (be it Microchip SAM9x60, or competing Rockchips or AllWinner) is a microcontroller wholly unsuitable for running Linux as we know it.
If you cannot reach 64MBs of RAM, Linux is simply unusable. Even for embedded purposes. You really should be using like FreeRTOS or something else at that point.
---------
Linux drawing the line at 64MB hardware built within the last 20 years is.... reasonable? Maybe too reasonable. I mean I love the fact that the SAM9x60 is still usable for modern and new designs but somewhere you have to draw the line.
ARMv5 is too old to compile even like Node.js. I'm serious when I say this stuff is old. It's an environment already alien to typical Linux users.
I'd expect that there were even cheaper processors now since it's eight years later.
dragontamer 8 days ago [-]
Microchip is always more expensive than the Chinese stuff, but Microchip contributions to Linux are mainline (!!!!), and is often worth the extra few $$$$.
Fully open hardware, with mainline Linux open source drivers. It's hard to beat SAM9x60 in openness, documentation and overall usability. It's specs are weaker but keeping up with mainline Linux is very, very relevant. Especially in this discussion
reactordev 9 days ago [-]
We need accessible open hardware. Not shoehorning proprietary hardware to make it work with generic standards they never actually followed.
Open source is one thing, but open hardware - that’s what we really need. And not just a framework laptop or a system76 machine. I mean a standard 64-bit open source motherboard, peripherals, etc that aren’t locked down with binary blobs.
AnthonyMouse 9 days ago [-]
> I mean a standard 64-bit open source motherboard, peripherals, etc that aren’t locked down with binary blobs.
The problem here is scale. Having fully-open hardware is neat, but then you end up with something like that Blackbird PowerPC thing which costs thousands of dollars to have the performance of a PC that costs hundreds of dollars. Which means that only purists buy it, which prevents economies of scale and prices out anyone who isn't rich.
Whereas what you actually need is for people to be able to run open code on obtainium hardware. This is why Linux won and proprietary Unix lost in servers.
That might be achievable at the low end with purpose-built open hardware, because then the hardware is simple and cheap and can reach scale because it's a good buy even for people who don't care if it's open or not.
But for the mid-range and high end, what we probably need is a project to pick whichever chip is the most popular and spend the resources to reverse engineer it so we can run open code on the hardware which is already in everybody's hands. Which makes it easier to do it again, because the second time it's not reverse engineering every component of the device, it's noticing that v4 is just v3 with a minor update or the third most popular device shares 80% of its hardware with the most popular device so adding it is only 20% as much work as the first one. Which is how Linux did it on servers and desktops.
skeezyboy 8 days ago [-]
> pick whichever chip is the most popular and spend the resources to reverse engineer it
is this even doable?
numpad0 8 days ago [-]
Not even hypothetical. See ATmega328P. It has no business being an actively supplied chip if we were to only care about technological supremacy of architectures and/or chip construction. Or countless "e8051" chips based on Intel 8051 microcontroller being https://xkcd.com/2347/ of USB.
FirmwareBurner 8 days ago [-]
Doable yes. Economical no.
AnthonyMouse 8 days ago [-]
It depends who you are and why you want it.
Could Amazon or Facebook do this if they just wanted to, e.g. to help break the hold of their competitors on markets they care about? Absolutely.
Could some hobbyist do it? Not on their own, but if you do part of it and someone else does part of it, the whole thing gets done. See e.g. Asahi Linux.
"The principle of evidence-based trust was at work in our decision to implement Precursor’s brain as an SoC on an FPGA, which means you can compile your CPU from design source and verify for yourself that Precursor contains no hidden instructions or other backdoors. Accomplishing the equivalent level of inspection on a piece of hardwired silicon would be…a rather expensive proposition. Precursor’s mainboard was designed for easy inspection as well, and even its LCD and keyboard were chosen specifically because they facilitate verification of proper construction with minimal equipment."
numpad0 9 days ago [-]
Lots of SoCs are "open" in the sense that complete documentation including programming manuals are available. With couple man-centuries of developer time each, you could port Linux over those SoCs. but that doesn't count as being "open". On the other hand, there are a lot of straight up proprietary hardware that are considered "open", like Raspberry Pi.
Which means, "open" has nothing to do with openness. What you want is standardization and commoditization.
There are practically no x86 hardware that require model-specific custom images to boot. There are practically no non-x86 hardware that don't require model-specific custom images to boot. ARM made perceptible amount of efforts in that segment with Arm SystemReady Compliance Program, which absolutely nobody in any serious businesses cares about, and it only concern ARM machines even if it worked.
IMO, one of problems in efforts going in from software side is over-bloated nature of desktop software stacks and bad experiences widely had with UEFI. They aren't going to upgrade RAM to adopt overbloated software that are bigger than the application itself just because that is the new standard.
rwmj 9 days ago [-]
Until we have affordable photolithography machines (which would be cool!), hardware is never really going to be open.
15155 9 days ago [-]
> affordable photolithography machines
We'll likely never have "affordable" photolithography, but electron beam lithography will become obtainable in my lifetime (and already is, DIY, to some degree.)
NooneAtAll3 9 days ago [-]
depends on what one means by affordable, but DIY versions have been successfully attempted
Making at home transistors, or even small-scale integrated circuits is not exceedingly difficult.
However, making at home a useful microcontroller or FPGA would require not only an electron-beam lithography machine, but also a ion-implantation machine, a diffusion furnace, a plasma-etch machine, a sputtering machine and a lot of other chemical equipment and measurement instruments.
All the equipment would have to be enclosed in a sealed room, with completely automated operation.
A miniature mask-less single-wafer processing fab could be made at a cost several orders of magnitude less than a real semiconductor fab, but the cost would still be of many millions of $.
With such a miniature fab, one might need a few weeks to produce a batch of IC's worth maybe $1000, so the cost of the equipment will never be recovered, which is why nobody does such a thing for commercial purposes.
In order to have distributed semiconductor fabs serving small communities around them, instead of having only a couple of fabs for the entire planet, one would need a revolution in the fabrication of the semiconductor manufacturing equipment itself, like SpaceX has done for rockets.
Only if the semiconductor manufacturing equipment would be the result of a completely automated mass production, which would reduce its cost by 2 or 3 orders of magnitude, affordable small-scale but state-of-the-art fabs would be possible.
But such an evolution is contrary to everything that the big companies have done during the last 30 years, during which all smaller competitors have been eliminated, the production has become concentrated in quasi-monopolies and for the non-consumer products the companies now offer every year more and more expensive models, which are increasingly affordable only for other big companies and not for individuals or small businesses.
bigiain 7 days ago [-]
> With such a miniature fab, one might need a few weeks to produce a batch of IC's worth maybe $1000
Maybe?
Another point of view might be that in a few weeks you could produce a batch of ICs you can actually trust, that would be several orders of magnitude more valuable than the $1000 worth of equivalents from the untrusted global supply chain.
15155 8 days ago [-]
> However, making at home a useful microcontroller or FPGA would require not only an electron-beam lithography machine, but also a ion-implantation machine, a diffusion furnace, a plasma-etch machine, a sputtering machine and a lot of other chemical equipment and measurement instruments.
> but the cost would still be of many millions of $.
A single set of this equipment is only singular millions today commercially.
Using something like this for prototyping/characterization or small-scale analog tasks is where the real win is.
adrian_b 8 days ago [-]
That ASU NanoFab has indeed almost everything that is needed.
It is weird that they do not have any ion implantation machine, because there are devices that are impossible to make without it. Even for simple MOS transistors, I am not aware of any other method for controlling the threshold voltage with enough precision. Perhaps whenever they need ion implantation they send the wafers to an external fab, with which they have a contract, to be done there.
Still, I find it hard to believe that all the equipment that they have costs less than 10 million $, unless it is bought second hand. There is indeed a market for slightly obsolete semiconductor manufacturing equipment, which has been replaced in some first tier fabs and now it is available at significant discounts for those who are content with it.
skeezyboy 8 days ago [-]
> one would need a revolution in the fabrication of the semiconductor manufacturing equipment itself, like SpaceX has done for rockets.
some revolution. still not even on the moon yet
Someone 8 days ago [-]
https://en.wikipedia.org/wiki/Moore%27s_second_law: “Rock's law or Moore's second law, named for Arthur Rock or Gordon Moore, says that the cost of a semiconductor chip fabrication plant doubles every four years”
Wafer machines from the 1970s could be fairly cheap today, if there were sufficient demand for chips from the 1970s (~1MHz, no power states, 16 bit if you’re lucky, etc), but that trend would have to stop and reverse significantly for affordable wafer factories for modern hardware to be a thing.
reactordev 9 days ago [-]
The next 3D print revolution, photolithography your own chip wafers at home. Now that would be something!
Insane… I thought I was smart, she proves me wrong.
jacquesm 9 days ago [-]
Peter Norvig, Fabrice Bellard, etc. The list of ultra smart people is quite long. A friend of mine thought he was pretty smart (and I would have happily agreed with him). Then he went to work for Google (early days). It didn't take long for him to realize that the only reason he seemed very smart was that he simply wasn't seeing a large enough slice of humanity.
quantummagic 9 days ago [-]
> I doubt anyone here has a clean enough room.
Jordan Peterson has entered the building...
lioeters 9 days ago [-]
"Clean your rooms, men!" Starts sobbing
aspenmayer 9 days ago [-]
Maybe if he cleaned his own room, he’d find his copy of the Communist Manifesto in time to read it for a scheduled debate.
"The principle of evidence-based trust was at work in our decision to implement Precursor’s brain as an SoC on an FPGA, which means you can compile your CPU from design source and verify for yourself that Precursor contains no hidden instructions or other backdoors. Accomplishing the equivalent level of inspection on a piece of hardwired silicon would be…a rather expensive proposition. Precursor’s mainboard was designed for easy inspection as well, and even its LCD and keyboard were chosen specifically because they facilitate verification of proper construction with minimal equipment."
This is somewhere in the 10x-100x more expensive and consumes much more power, for lower effective clock speeds. It's not a production solution.
mardifoufs 8 days ago [-]
In addition to what the other comments have already highlighted, there's also the fact that you'd be back to using extremely opaque, even less "open source" hardware than regular CPUs/MCUs. Almost every FPGA that could even conceivably be used to run general purpose software is locked behind super proprietary stacks
TheAmazingRace 9 days ago [-]
We kinda have this with IBM POWER 9. Though that chip launched 8 years ago now, so I'm hoping IBM's next chip can also avoid any proprietary blobs.
reactordev 9 days ago [-]
Indeed with the OpenPOWER foundation.
Let’s hope some of that trickles down to consumer hardware.
stonogo 9 days ago [-]
Unlikely: POWER10 required blobs, and there's no sign that'll change for Power 11.
8 days ago [-]
tonyhart7 9 days ago [-]
I would love to works with hardware, if you can foot my bill then I be happy to do that
since open source software is one thing but open source hardware need considerable investment that you cant ignore from the start.
also this is what happen to prusa, everyone just take the design and outsource the manufacture to somewhere in china which is fine but if everybody doing that, there is no fund to develop next iteration of product (someone has to foot the bill)
and there is not enough sadly, we live in reality after all
pjc50 8 days ago [-]
> Open source is one thing, but open hardware - that’s what we really need
This needs money. It is always going to have to pay the costs of being niche, lower performance, and cloneable, so someone has to persuade people to pay for that. Hardware is just fundamentally different. And that's before you get into IP licensing corner cases.
eric__cartman 9 days ago [-]
Those operating systems already exist. You can run NetBSD on pretty much anything (it currently supports machines with a Motorola 68k CPU for example). Granted many of those machines still have an MMU iirc but everything is still simple enough to be comprehend by a single person with some knowledge in systems programming.
jmclnx 9 days ago [-]
FWIW, Linux is not the only OS looking into dropping 32bit.
For 32bit, I guess NetBSD may eventually be the only game in town.
kimixa 9 days ago [-]
NetBSD doesn't support any devices without an mmu.
I think people here are misunderstanding just how "weird" and hacky trying to run an OS like linux on those devices really is.
kbolino 9 days ago [-]
Yeah, a lot of what defines "operating system" for us nowadays is downstream of having memory isolation.
Not having an MMU puts you more into the territory of DOS than UNIX. There is FreeDOS but I'm pretty sure it's x86-only.
actionfromafar 9 days ago [-]
Mmm... would beg to differ. I have ported stuff to NOMMU Linux and almost everything worked just as on a "real" Linux. Threads, processes (except only vfork, no fork), networking, priorities, you no name it. DOS gives you almost nothing. It has files.
The one thing different to a regular Linux was that a crash of a program was not "drop into debugger" but "device reboots or halts". That part I don't miss at all.
beeflet 9 days ago [-]
This was interesting. It reminded me how fork() is so weird and I found some explanation for its weirdness that loops back to this conversation about nommu:
"Originally, fork() didn't do copy on write. Since this made fork() expensive, and fork() was often used to spawn new processes (so often was immediately followed by exec()), an optimized version of fork() appeared: vfork() which shared the memory between parent and child. In those implementations of vfork() the parent would be suspended until the child exec()'ed or _exit()'ed, thus relinquishing the parent's memory. Later, fork() was optimized to do copy on write, making copies of memory pages only when they started differing between parent and child. vfork() later saw renewed interest in ports to !MMU systems (e.g: if you have an ADSL router, it probably runs Linux on a !MMU MIPS CPU), which couldn't do the COW optimization, and moreover could not support fork()'ed processes efficiently.
Other source of inefficiencies in fork() is that it initially duplicates the address space (and page tables) of the parent, which may make running short programs from huge programs relatively slow, or may make the OS deny a fork() thinking there may not be enough memory for it (to workaround this one, you could increase your swap space, or change your OS's memory overcommit settings). As an anecdote, Java 7 uses vfork()/posix_spawn() to avoid these problems.
On the other hand, fork() makes creating several instances of a same process very efficient: e.g: a web server may have several identical processes serving different clients. Other platforms favour threads, because the cost of spawning a different process is much bigger than the cost of duplicating the current process, which can be just a little bigger than that of spawning a new thread. Which is unfortunate, since shared-everything threads are a magnet for errors."
That's fair. If so, then you still can have things like drivers and HAL and so on too. However, there's no hard security barriers.
How do multiple processes actually work, though? Is every executable position-independent? Does the kernel provide the base address(es) in register(s) as part of vfork? Do process heaps have to be constrained so they don't get interleaved?
jlokier 9 days ago [-]
There are many options. Executables can be position-independent, or relocated at run-time, or the device can have an MPU or equivalent registers (for example 8086/80286 segment registers), which is related to an MMU but much simpler.
Executables in a no-MMU environment can also share the same code/read-only segments between many processees, the same way shared libraries can, to save memory and, if run-time relocation is used, to reduce that.
The original design of UNIX ran on machines without an MMU, and they had fork(). Andrew Tanenbaum's classic book which comes with Minix for teaching OS design explains how to fork() without an MMU, as Minix runs on machines without one.
For spawning processes, vfork()+execve() and posix_spawn() are much faster than fork()+execve() from a large process in no-MMU environments though, and almost everything runs fine with vfork() instead of fork(), or threads. So no-MMU Linux provides only vfork(), clone() and pthread_create(), not fork().
kbolino 9 days ago [-]
Thanks! I was able to find some additional info on no-MMU Linux [1], [2], [3]. It seems position-independent executables are the norm on regular (MMU) Linux now anyway (and probably have been for a long time). I took a look under the covers of uClibc and it seems like malloc just delegates most of its work to mmap, at least for the malloc-simple implementation [4]. That implies to me that different processes' heaps can be interleaved (without overlapping), but the kernel manages the allocations.
Under uClinux, executables can be position independent or not. They can run from flash or RAM. They can be compressed (if they run in RAM). Shared libraries are supported on some platforms. All in all it's a really good environment and the vfork() limitation generally isn't too bad.
I spent close to ten years working closely with uClinux (a long time ago). I implemented the shared library support for the m68k. Last I looked, gcc still included my additions for this. This allowed execute in place for both executables and shared libraries -- a real space saver. Another guy on the team managed to squeeze the Linux kernel, a reasonable user space and a full IP/SEC implementation into a unit with 1Mb of flash and 4Mb of RAM which was pretty amazing at the time (we didn't think it was even possible). Better still, from power on to login prompt was well under two seconds.
inkyoto 9 days ago [-]
> The original design of UNIX ran on machines without an MMU, and they had fork().
The original UNIX also did not have the virtual memory as we know it today – page cache, dynamic I/O buffering, memory mapped files (mmap(2)), shared memory etc.
They all require a functioning MMU, without which the functionality would be severely restricted (but not entirely impossible).
jlokier 8 days ago [-]
Those features don't require an MMU.
The no-MMU version of Linux has all of those features except that memory-mapped files (mmap) are limited. These features are the same as in MMU Linux: page cache, dynamic I/O buffering, shared memory. No-MMU Linux also supports other modern memory-related features, like tmpfs, futexes. I think it even supoprts io_uring.
That is not how a VMM subsystem works, irrespective of the operating system, be it Linux, or Windows, or a BSD, or z/OS. The list goes on.
Access to a page that is not resident in memory results in a trap (an interrupt), which is handled by the MMU – the CPU has no ability to do it by itself. Which is the whole purpose of the MMU and was a major innovation of BSD 4 (a complete VMM overhaul).
jlokier 8 days ago [-]
You're right about the VMM.
But three out of those four features: page cache, dynamic I/O buffering and shared memory between processes, do not require that kind of VMM subsystem, and memory-mapped files don't require it for some kinds of files.
I've worked on the Linux kernel and at one time understood it's mm intimately (I'm mentioned in kernel/futex/core.c).
I've also worked on uClinux (no-MMU) systems, where the Linux mm behaves differently to produce similar behaviours.
I found most userspace C code and well-known CLI software on Linux and nearly all drivers, networking features, storage, high-performance I/O, graphics, futex, etc run just as well on uClinux without source changes, as long as there's enough memory, with some more required because uClinux suffers from a lot more memory fragmentation due to needing physically-contiguous allocations).
This makes no-MMU Linux a lot more useful and versatile than alternative OSes like Zephyr for similar devices, but the limitations and unpredictable memory fragmentation issues make it a lot less useful than Linux with an MMU, even if you have exactly the same RAM and no security or bug concerns.
I'd always recommend an MMU now, even if it's technically possible for most code to run without one.
8 days ago [-]
saati 8 days ago [-]
The original UNIX literally swapped processes, as in write all their memory to disk and read another program's state from disk to memory, it could only run as many processes as many times the swap was bigger than core, this is a wholly unacceptable design nowadays.
inkyoto 8 days ago [-]
It also supported overlays on the PDP-11, although not in the beginning. I do not think that anybody makes use of the overlays anymore.
int_19h 9 days ago [-]
In an embedded scenario where the complete set of processes that are going to be running at the same time is known in advance, I would imagine that you could even just build the binaries with the correct base address in advance.
actionfromafar 8 days ago [-]
A common trick to decrease code size in RAM, is to link everything to a single program, then have the program check its argv[0] to know which program to call.
With the right filesystem (certain kinds of read-only), the code (text segment) can even be mapped directly, and no loading into RAM need occur at all.
These approaches saves memory even on regular MMU platforms.
arp242 9 days ago [-]
To clarify: NetBSD has never supported non-MMU systems, or at least hasn't for decades. As opposed to something they removed recently(-ish).
duskwuff 9 days ago [-]
nommu is a neat concept, but basically nobody uses it, and I don't see that as likely to change. There's no real use case for using it in production environments. RTOSes are much better suited for use on nommu hardware, and parts that can run "real" Linux are getting cheaper all the time.
If you want a hardware architecture you can easily comprehend - and even build your own implementation of! - that's something which RISC-V handles much better than ARM ever did, nommu or otherwise.
speed_spread 9 days ago [-]
There's plenty of use cases for Linux on microcontrollers that will be impossible if nommu is removed. The only reason we don't see more Linux on MCUs is the lack of RAM. RP2350 are very close! Running Linux makes it much easier to develop than a plain RTOS.
Brian_K_White 9 days ago [-]
Linux, or any other full OS is simply a waste of that hardware. It makes no sense at all.
It's a 5 gallon pail of compute which is all used up in OS overhead so you can do a cup of work.
If the job were that small that it fits in the remainder, then you could and should have just used 1 cent hardware instead of 1 dollar hardware.
speed_spread 9 days ago [-]
Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead. Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
duskwuff 9 days ago [-]
> Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead.
As a reality check: MicroPython can run in 16 KB of RAM; a typical development board has 192 KB. µCLinux requires at least 4 - 8 MB of RAM just to boot up, and recommends 32 MB for a "serious product" [1].
> Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
I would absolutely not count on any of those tools being available and functional in a µCLinux environment.
> µCLinux [...] recommends 32 MB for a "serious product"
My point exactly. There's currently a hole between ten-cent MCUs requiring RTOS and 5$+ RPi that can run Linux. Taking out nommu from the kernel would make any 64MB "super-MCU" a non-starter.
duskwuff 6 days ago [-]
You might be surprised how inexpensive a small Linux-capable MPU is. The Rockchip RV1103 (1x Cortex-A7 @ 1.2 GHz, 64 MB integrated DRAM) is under $3 in quantity. High-end microcontrollers are actually more expensive than low-end MPUs, e.g. STM32N6 is $15-20.
actionfromafar 8 days ago [-]
I used Ethernet, USB and some serial thingy (I2C? can't remember) without issue.
duskwuff 9 days ago [-]
> Running Linux makes it much easier to develop than a plain RTOS.
I'm not convinced that's true. All of the microcontroller tooling I've seen has been built around RTOS development; I've never seen anything comparable for µCLinux.
leoedin 8 days ago [-]
Setting up and maintaining a custom Linux build for any hardware is pretty complicated. There's just so much complexity hidden under config options. The landscape of Linux for embedded computers is a huge mess of unmaintained forks and hacky patch files.
That's all worth it to have an application processor that can run your Python/Java app. It's probably worth it to have a consistent operating system across multiple devices.
Would you have many of those benefits if you were using Linux on a micro though? I can't imagine much 3rd party software would work reliably given the tiny amount of RAM. You'd basically just be using it as a task scheduler and wrapper over drivers. You could get most of the benefits by using an RTOS with a memory allocator.
snvzz 9 days ago [-]
A "plain RTOS" is the better idea most of the time.
topspin 9 days ago [-]
That may change. There are some very powerful MCUs appearing, with astonishing features, including hardware virtualization (hypervisors on an MCU,) multicore superscalar, heterogeneous CPU cores with high performance context switching, "AI" co-processors with high throughput buses, and other exotic features.
At some point, it might start making sense to level up the OS to (nommu) Linux on these devices. When the applications get complex enough, people find themselves wanting a full blown network stack, full featured storage/file systems that are aligned with non-embedded systems, regular shells, POSIX userland, etc.
All of the architectures I have in mind are 32 bit and "nommu"[1]: Cortex-R52/F, Infineon TriCore, Renesas RH850, NXP Power e200. Then you have RISC-V MCU Cambrian Explosion underway.
I qualify all this with mays and mights: it hasn't happened yet. I'm just careful not to discount the possibly of a <50 mAh RP Pico 3 booting uLinux, running python and serving web pages being a big hit.
[1] They all have various "partition" schemes to isolate banks of RAM for security, reliability, etc., but real MMUs are not offered.
leoedin 8 days ago [-]
I've spent quite a lot of the last year setting up an embedded Linux device for mass deployment - so I've seen a lot of its downsides first hand.
When you have a fleet of embedded devices you want pre-compiled disk images, repeatable builds, read only filesystems, immutable state (apart from small and well controlled partitions), easy atomic updates, relatively small updates (often devices are at the other end of a very slow cell connection) and a very clear picture of what is running on every device in your fleet.
Linux can do all that, but it's not the paradigm that most distros take. Pretty much the entire Linux world is built around mutable systems which update in place. So you're left to manage it yourself. If you want to do it yourself, you end up in the hacky fragile world of Yocto.
Compared to that, using an RTOS or application framework like Zephyr is fairly easy - at the expense of app development time, you just need to worry about getting a fairly small compiled binary onto your device.
I do agree that there's some really powerful parts available which would benefit from the shared drivers and consistent syscalls a standardised operating system offers. But building and maintaining a Linux system for any part isn't a simple undertaking either - and so the complexity of that needs to be considered in total development time.
8 days ago [-]
snvzz 9 days ago [-]
Generally, MCU people want predictable behavior and small TCB.
Linux is too unorthogonal for them.
pjc50 8 days ago [-]
There's no evidence that significant numbers of people are actually doing that, though.
RossBencina 8 days ago [-]
> Running Linux makes it much easier to develop than a plain RTOS.
What's missing? What would it take to make a plain RTOS that's as easy to develop on/for/with as Linux?
MisterTea 8 days ago [-]
> Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings.
Simple and POSIX would be a BSD like NetBSD or OpenBSD.
This is why I gravitated to Plan 9. Overall a better design for a networked world and can be understood by a single developer. People can and have maintained their own forks. Its very simple, small and cross platform was baked in from day one. 9P makes everything into a IO socket organized as a tree of names objects. Thankfully it's not POSIX which IMO is not worth dragging along for decades. You can port Unix things with libraries. It also abandons the typewriter terminal and instead uses graphics. A fork, 9front, is not abandoning 32 bit any time soon AFIK. I netboot an older Industrial computer that is a 400MHz Geode (32 bit x86) with 128 MB RAM and it runs 9front just fine.
Its not perfect and lacks features but that stands to reason for any niche OS without a large community. Figure out what is missing for you and work on fixing it - patches welcome.
pajko 8 days ago [-]
Why do you need a full blown Linux for that? Much of the provided features are overkill for such embedded systems. Both NuttX and Zephyr provide POSIX(-like) APIs, NuttX has an API quite similar to the Linux kernel, so it should be somewhat easier to port missing stuff (have not tried to do that, the project I was working on got cancelled)
Denvercoder9 9 days ago [-]
If you want a POSIX OS, nommu Linux already isn't it: it doesn't have fork().
em3rgent0rdr 9 days ago [-]
Just reading about this...turns out nommu Linux can use vfork(), which unlike fork() shares the parent's address space. Another drawback is that vfork's parent process gets suspended until the child exits or calls execve().
actionfromafar 9 days ago [-]
Typicall you always call vfork() + execve(), vfork is pretty useless on its own.
Think about it like CreateProcess() on Windows. Windows is another operating system which doesn't support fork(). (Cygwin did unholy things to make it work anyway, IIRC.)
trebligdivad 9 days ago [-]
There are some other open OSs, like Zephyr, NuttX and Contiki - so maybe they're the right thing to use for the nommu case rather than Linux?
RantyDave 9 days ago [-]
Zephyr is not an OS in the conventional sense, it's more a library you link to so the application can "go".
ajross 9 days ago [-]
Zephyr is an "OS" in pretty much every conventional sense. What you're saying, I think, is that a default build of Zephyr on a no-MPU device is a single shared .text segment where all the threads and other OS-managed objects are app-created by C code. So... sure, it's a library and an OS. And even when running on a system with an MPU/MMU, Zephyr tries hard to present that same API (i.e. function calls into the kernel become syscalls automatically, etc...), so the illusion is a fairly strong one.
And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it).
If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.
Two things standout to me: (1) It was written in 2006. RISC V was not released until 2010 (so says Google). I guess it was ported from x86? (2) Russ Cox is one of the contacts listed on MIT homepage. That guy's digital footprints are enormous.
vulcan01 8 days ago [-]
Yes, it was ported from x86. And no, xv6 is not really an OS you want to use in production. There are a lot of design decisions that optimize for pedagogy instead of performance or even reliability (e.g. the kernel is more than happy to panic if/when you get off the "intended path").
s20n 9 days ago [-]
xv6-riscv was designed to run on qemu-virt, not real hardware. you'll atleast need to use a fork like https://github.com/jrmenzel/vimix_os to get it to work on a real board.
JoshTriplett 9 days ago [-]
I don't think it makes sense to run Linux on most nommu hardware anymore. It'd make more sense to have a tiny unikernel for running a single application, because on nommu, you don't typically have any application isolation.
duskwuff 9 days ago [-]
> on nommu, you don't have any application isolation
That isn't necessarily the case. You can have memory protection without a MMU - for instance, most ARM Cortex-M parts have a MPU which can be used to restrict a thread's access to memory ranges or to hardware. What it doesn't get you is memory remapping, which is necessary for features like virtual memory.
tombl 9 days ago [-]
Yeah, nommu absolutely doesn't imply zero memory isolation. I have a kernel port to an architecture with a nonstandard way of doing memory isolation and the existing nommu infrastructure is the only reason it can exist.
rasz 9 days ago [-]
virtual memory as in swap is one, but imo bigger one is memory-mapped files
pjmlp 8 days ago [-]
There are plenty of FOSS POSIX like for such systems.
Most likely I won't be around this realm when that takes shape, but I predict the GNU/Linux explosion replacing UNIX was only a phase in computing history, eventually when everyone responsible for its success fades away, other agendas will take over.
It is no accident that the alternatives I mention, are all based on copyleft licenses.
chasil 9 days ago [-]
This is a foreseeable cataclysm for me, as I retire next year, and the core of our queing system is 64-bit clean (k&r) as it compiled on Alpha, but our client software is very much not.
This is a young mans' game, and I am very much not.
noobermin 8 days ago [-]
You're not alone, I feel the same way. I think the future if linux really will need to remove nommu would be a fork. I'm not sure if there's the community for that though.l
Blammmoklo 9 days ago [-]
Supporting 32bit is not 'simple' and the difference between 32bit hardware and 64bit hardware is not big.
The industry has a lot of experience doing so.
In parallel, the old hardware is still supported, just not by the newest Linux Kernel. Which should be fine anyway because either you are not changing anything on that system anyway or you have your whole tool stack available to just patch it yourself.
But the benefit would be a easier and smaller linux kernel which would probably benefit a lot more people.
Also if our society is no longer able to produce chips in a commercial way and we loose all the experience people have, we are probably having a lot bigger issues as a whole society.
But I don't want to deny that it would be nice to have the simplest way of making a small microcontroller yourself (doesn't has to be fast or super easy just doable) would be very cool and could already solve a lot of issues if we would need to restart society from wikipedia.
mort96 9 days ago [-]
The comment you're responding to isn't talking about 32 vs 64 bit, but MMU vs no MMU.
cout 9 days ago [-]
ELKS can still run on systems without an mmu (though not microcontrollers afaik).
snvzz 9 days ago [-]
ELKS runs 16bit x86, including 8086.
Note ELKS is not Linux.
There's also Fuzix.
762236 9 days ago [-]
Removing nommu makes the kernel simpler and easier to understand.
ohdeargodno 9 days ago [-]
Nothing prevents you from maintaining nommu as a fork. The reality of things is, despite your feelings, people have to work on the kernel, daily, and there comes a point where your tinkering needs do not need to be supported in main. You can keep using old versions of the kernel, too.
Linux remains open source, extendable, and someone would most likely maintain these ripped out modules. Just not at the expense of the singular maintainer of the subsystem inside the kernel.
stephen_g 9 days ago [-]
> there comes a point where your tinkering needs do not need to be supported in main.
Linux's master branch is actually called master. Not that it really matters either way (hopefully most people have realised by now that it was never really 'non-inclusive' to normal people) but pays to be accurate.
saagarjha 8 days ago [-]
This seems like a dumb thing to be pedantic about, actually
llbbdd 9 days ago [-]
What is meant by inclusive here? I'm having trouble following this comment other than the clarification to the name.
stephen_g 9 days ago [-]
The context is that many people (and especially public repositories from US companies) started changing the name to ‘main’ out of a misguided inclusivity push that comes from a niche political theory that says even if words aren’t slurs (which obviously should be avoided), if a word has a meaning that could possibly be connected to anything that could possibly be in any way sensitive to anybody, then we need to protect people from seeing the word.
In this case, out of dozens of ways the word is used (others being like ‘masters degree’ or ones that pretty closely match Git’s usage like ‘master recording’ in music), one possible one is ‘slavemaster’, so some started to assert we have to protect people from possibly making the association.
1718627440 6 days ago [-]
Even if the term master where about that, I don't get, what's the problem. Having slaves is wrong, because these are human beings. Having other things like machines as slaves is not immoral. We also treat animals way worse then slaves and these are animate objects. And nobody objects to robot, which is just the word slave in czech.
The relation between a human and a computer is very much that of a master and a slave. I provide the resources, you do what I say, including self-destruction.
bjourne 8 days ago [-]
I think the amount of whines proved the inclusivity people right. Fwiw, in git the main branch doesn't dominate the other branches and it is not an expert so it is not a master. It is main in the same way the main street in a city is main.
llbbdd 7 days ago [-]
Ah okay, I remember this. I'm not sure the they were proved right that conclusively - from my neck of the woods it seemed like it invented issues where there weren't any previously. And maybe that was the point - I wasn't involved. But where I was, the terminology wasn't controversial until it was, and that seemed to be a choice (maybe by Github to follow social convention).
ohdeargodno 8 days ago [-]
I wish there were strong enough words to tell you about how few shits I give about the name of a branch.
> Not that it really matters either way
But you still decided to make it your personal battle to make a comment remind people that the evil inclusive people did a no no by forcing you to rename your branches from master to main, yes.
>pays to be accurate.
No, it doesn't. Source: you knew exactly what I was talking about when I said main. You also would have known what I was talking about had I said trunk, master, develop or latest.
jnwatson 9 days ago [-]
It is amazing that big endian is almost dead.
It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC.
Main-core computing is vastly more homogenous than when I was born almost 50 years ago. I guess that's a natural progression for technology.
goku12 9 days ago [-]
> It is amazing that big endian is almost dead.
I wish the same applied to written numbers in LTR scripts. Arithmetic operations would be a lot easier to do that way on paper or even mentally. I also wish that the world would settle on a sane date-time format like the ISO 8601 or RFC 3339 (both of which would reverse if my first wish is also granted).
> It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC.
I never really understood those non-8-bit bytes, especially the 7 bit byte. If you consider the multiplexer and demux/decoder circuits that are used heavily in CPUs, FPGAs and custom digital circuits, the only number that really makes sense is 8. It's what you get for a 3 bit selector code. The other nearby values being 4 and 16. Why did they go for 7 bits instead of 8? I assume that it was a design choice made long before I was even born. Does anybody know the rationale?
idoubtit 9 days ago [-]
> I also wish that the world would settle on a sane date-time format like the ISO 8601
IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.
There's mainly one country which messes things up...
tavavex 9 days ago [-]
YYYY-MM-DD is also the official date format in Canada, though it's not officially enforced, so outside of government documents you end up seeing a bit of all three formats all over the place. I've always used ISO 8601 and no one bats an eye, and it's convenient since YYYY-DD-MM isn't really a thing, so it can't be confused for anything else, unlike the other two formats.
zahlman 9 days ago [-]
YMD has caught on, I think, because it allows for the numbers to be "in order" (not mixed-endian) while still having the month before the day which matches the practice for speaking dates in (at least) the US and Canada.
adgjlsfhk1 9 days ago [-]
The primary reason for YMD is that DDMMYYYY is ambiguous with MMDDYYYY
christophilus 9 days ago [-]
It is also sortable, which I think is the real advantage.
globular-toast 8 days ago [-]
I used to think this was really important, but what's the use case here?
If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?
On the other hand, if it's data for computer consumption then just skip the complicated serialisation completely and dump the Unix timestamp as a decimal. Any modern data format would include the ability to label that as a timestamp data type. If you really want to be able to "read" the data file then just include another column with a human-formatted timestamp, but I can't imagine why in 2025 I would be manually reading through a data file like some ancient mathematician using a printed table of logarithms.
Majestic121 8 days ago [-]
> If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?
If you're naming a document for human consumption, having the files sorted by date easily without relying on modification date (which is changed by fixing a typo/etc...) is pretty neat
bombcar 8 days ago [-]
This is exactly it - file name is easy to control and sort on; creates date and modified date are (for most users) random and uncontrolled.
globular-toast 8 days ago [-]
So you can't sort by name, author etc? One sort key? What year is it?!
privatelypublic 9 days ago [-]
As ling as you pad to two characters!
rocqua 9 days ago [-]
8601, when used fully according to spec sucks. It makes today 20250902. It doesn't have seperators. And for adding a time it gets even less readable.
Its a serialization and machine communication format. And that makes me sad. Because YYYY-MM-DD is a great format, without a good name.
em500 8 days ago [-]
YYYY-MM-DD is ISO8601 extended format, YYYYMMDD is ISO8601 basic format (section 5.2.1.1 of ISO8601:2000(E)[1]). Both are fully according to spec, and neither format takes precedence over the other.
It does have a good name: RFC 3339. Unlike the ISO standard, that one mandates the "-" separators. Meanwhile it lets you substitute a space for the ugly "T" separator between date and time:
> NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
Y_Y 8 days ago [-]
I always like the compromise of the M/D/M system popularised by the British documentary series Look Around You, e.g. "January the fourth of March".
christophilus 9 days ago [-]
I live in that country, and I am constantly messing up date forms. My brain always goes yyyy-mm-dd. If I write it out, September 1st, 2025, I get it in the “right” order. But otherwise, especially if I’m tired, it’s always in a sortable format.
pavon 9 days ago [-]
There are a lot of computations where 256 is too small of a range but 65536 is overkill. When designers of early computers were working out how many digits of precision their calculations needed to have for their intended purpose 12 bits commonly ended up being a sweet spot.
When your RAM is vacuum tubes or magnetic core memory, you don't want 25% of it to go unused, just to round your word size up a power of two.
skeezyboy 8 days ago [-]
> There are a lot of computations where 256 is too small of a range but 65536 is overkill
wasnt this more to do with cost? they could do arbitrary precision code even back then. its not like they were only calculating numbers less than 65537, ignoring anything larger
jcranmer 9 days ago [-]
I don't know that 7-bit bytes were ever used. Computer word sizes have historically been multiples of 6 or 8 bits, and while I can't say as to why particular values were chosen, I would hypothesize that multiples of 6 and 8 work well for representation in octal and hexadecimal respectively. For many of these early machines, sub-word addressability wasn't really a thing, so the question of 'byte' is somewhat academic.
For the representation of text of an alphabetic language, you need to hit 6 bits if your script doesn't have case and 7 bits if it does have case. ASCII ended up encoding English into 7 bits and EBCDIC chose 8 bits (as it's based on a binary-coded decimal scheme which packs a decimal digit into 4 bits). Early machines did choose to use the unused high bit of an ASCII character stored in 8 bits as a parity bit, but most machines have instead opted to extend the character repertoire in a variety of incompatible ways, which eventually led to Unicode.
cardiffspaceman 9 days ago [-]
On the DEC-10 the word size is 36 bits. There was (an option to include) a special set of instructions to enable any given byte size with bytes packed. Five 7-bit bytes per word, for example, with a wasted bit in each word.
I wouldn’t be surprised if other machines had something like this in hardware.
Affric 9 days ago [-]
Could you use the extra bit for parity?
cardiffspaceman 8 days ago [-]
I don’t remember if there are instructions for putting any value of parity as such into the spare bit.
int_19h 9 days ago [-]
> For the representation of text of an alphabetic language, you need to hit 6 bits if your script doesn't have case
Only if you assume a 1:1 mapping. But e.g. the original Baudot code was 5-bit, with codes reserved to switch between letters and "everything else". When ASCII was designed, some people wanted to keep the same arrangement.
dboreham 9 days ago [-]
Quick note that parity was never used in "characters stored". It was only ever used in transmission, and checked/removed by hardware[1].
[1] Yes, I remember you could bit-bang a UART in software, but still the parity bit didn't escape the serial decoding routine.
goku12 9 days ago [-]
I wasn't asking about word sizes in particular, and had ASCII in mind. Nevertheless, your answer is in the right direction.
creshal 8 days ago [-]
> both of which would reverse if my first wish is also granted
But why? The brilliance of 8601/3339 is that string sorting is also correct datetime sorting.
goku12 8 days ago [-]
> But why?
To get the little-endian ordering. The place values of digits increase from left to right - in the same direction as how we write literature (assuming LTR scripts), allowing us to do arithmetic operations (addition, multiplication, etc) in the same direction.
> The brilliance of 8601/3339 is that string sorting is also correct datetime sorting.
I hadn't thought about that. But it does reveal something interesting. In literature, we assign the highest significance to the left-most (first) letter - in the direction opposite to how we write. This needs a bit more contemplation.
1718627440 6 days ago [-]
> we assign the highest significance to the left-most (first) letter
Yes, we do that with everything, which is why little-endian numbers would be really inconsistent for humans.
formerly_proven 9 days ago [-]
Computers never used 7-bit bytes similarly to how 5-bit bytes were uncommon, but both 6-bit and 8-bit bytes were common in their respective eras.
goku12 9 days ago [-]
I was asking about ASCII encoding and not the word size. But this information is also useful. So apparently, people were representing both numbers and script codes (EBCDIC in particular) in packed decimal or octal at times. The standardization on 8 bits and adoption of raw binary representation seems to have come later.
formerly_proven 8 days ago [-]
Because character encodings were primarily designed around transmission over serial lines.
goku12 8 days ago [-]
Agreed. But how does that affect how encoding are designed? I mean packed decimal vs octal vs full binary, etc?
blahedo 9 days ago [-]
I believe that 10- and 12-bit bytes were also attested in the early days. As for "why": the tradeoffs are different when you're at the scale that any computer was at in the 70s (and 60s), and while I can't speak to the specific reasons for such a choice, I do know that nobody was worrying about scaling up to billions of memory locations, and also using particular bit combinations to signal "special" values was a lot more common in older systems, so I imagine both were at play.
globular-toast 8 days ago [-]
In Britain the standard way to write a date has always been, e.g "12th March 2023” or 12/3/2023 for short. Don't think there's a standard for where to put the time, though, I can imagine it both before and after.
Doing numbers little-endian does make more sense. It's weird that we switch to RTL when doing arithmetic. Amusingly the Wikipedia page for Hindu-Arabic numeral system claims that their RTL scripts switch to LTR for numbers. Nope... the inventors of our numeral system used little-endian and we forgot to reverse it for our LTR scripts...
Edit: I had to pull out Knuth here (vol. 2). So apparently the original Hindu scripts were LTR, like Latin, and Arabic is RTL. According to Knuth the earliest known Hindu manuscripts have the numbers "backwards", meaning most significant digit at the right, but soon switched to most significant at the left. So I read that as starting in little-endian but switching to big-endian.
These were later translated to Arabic (RTL), but the order of writing numbers remained the same, so became little-endian ("backwards").
Later still the numerals were introduced into Latin but, again, the order remained the same, so becoming big-endian again.
goku12 8 days ago [-]
We in India use the same system for dates as you described, for obvious reasons. But I really don't like the pattern of switching directions multiple times when reading a date and time.
And as for numbers, perhaps it isn't too late to set it right once and for all. The French did that with the SI system after all.
> So apparently the original Hindu scripts were LTR
I can confirm. All Indian scripts are LTR (Though there are quite a few of them. I'm not aware of any exceptions). All of them seem to have evolved from an ancient and now extinct script named Brahmi. That one was LTR. It's unlikely to have switched direction any time during subsequent evolution into modern scripts.
1718627440 6 days ago [-]
> I also wish that the world would settle on a sane date-time format like the ISO 8601 or RFC 3339 (both of which would reverse if my first wish is also granted).
YYYY-MM-DD to me always feels like a timestamp, while when I want to write a date, I think of a name, (for me DD. MM. YYYY).
vrighter 8 days ago [-]
7 bits was chosen to reduce transmission costs, not storage costs, because you send 12.5% less data. Also, because computers usually worked on 8-bit bytes, the 8th bit could be used as a parity bit, where extra reliability was needed.
9 days ago [-]
ndiddy 9 days ago [-]
Big endian will stay around as long as IBM continues to put in the resources to provide first-class Linux support on s390x. Of course if you don’t expect your software to ever be run on s390x you can just assume little-endian, but that’s already been the case for the vast majority of software developers ever since Apple stopped supporting PowerPC.
metaphor 9 days ago [-]
> ...that’s already been the case for the vast majority of software developers ever since Apple stopped supporting PowerPC.
For better or worse, PowerPC is still quite entrenched in the industrial embedded space.
ndiddy 9 days ago [-]
Right, and the vast majority of software developers aren't writing software intended to run on PowerPC industrial control boards.
Aardwolf 9 days ago [-]
Now just UTF-16 and non '\n' newline types remaining to go
syncsynchalt 9 days ago [-]
Of the two UTF-16 is much less of a problem, it's trivially[1] and losslessly convertible.
[1] Ok I admit, not trivially when it comes to unpaired surrogates, BOMs, endian detection, and probably a dozen other edge and corner cases I don't even know about. But you can offload the work to pretty well-understood and trouble-free library calls.
Aardwolf 9 days ago [-]
It causes such issues as opening of files by filename not being cross platform with standard libc functions since in Windows w-string versions are required since UTF-16 chars can have 0-bytes that aren't zero terminators
codedokode 8 days ago [-]
It makes sense because UTF-16 is a sequence of uint16_t values, so both bytes must be zero, not just one.
syncsynchalt 8 days ago [-]
Yes, it makes sense, but it still resulted in a lot of work.
Most Unix syscalls use C-style strings, which are a string of 8-bit bytes terminated with a zero byte. With many (most?) character encodings you can continue to present string data to syscalls in the same way, since they often also reserved a byte value of zero for the same purpose. Even some multi-byte encodings would work if they chose to avoid using 0-value bytes for this reason.
UTF-16LE/BE (and UTF-32 for that matter) chose not to allow for this, and the result is that if you want UTF-16 support in your existing C-string-based syscalls you need to make a second copy of every syscall which supports strings in your UTF-16 type of choice.
codedokode 7 days ago [-]
> Most Unix syscalls use C-style strings, which are a string of 8-bit bytes terminated with a zero byte. With many (most?) character encodings you can continue to present string data to syscalls in the same way, since they often also reserved a byte value of zero for the same purpose
That's completely wrong. If a syscall (or a function) expects text in encoding A, you should not be sending it in encoding B because it would be interpreted incorrectly, or even worse, this would become a vulnerability.
For every function, encoding must be specified as are specified the types of arguments, constraints and ownership rules. Sadly many open source libraries do not do it. How are you supposed to call a function when you don't know the expected encoding?
Also, it is better to send a pointer and a length of the string rather than potentially infinitely search for a zero byte.
> and the result is that if you want UTF-16 support in your existing C-string-based syscalls
There is no need to support multiple encodings, it only makes things complicated. The simplest solution would be to use UTF-8 for all kernel facilities as a standard.
For example, it would be better if open() syscall required valid UTF-8 string for a file name. This would leave no possibility for displaying file names as question marks.
1718627440 6 days ago [-]
Why should the OS mess with application data? I think syscalls should treat text as the blob it is and not care about the encoding at all.
codedokode 6 days ago [-]
File name is a string, not a blob.
1718627440 6 days ago [-]
Yes and my argument is that the OS should treat strings as a blob and not care about the encoding. How can it know what shiny new encoding the program uses? Encoding is a concern of the program, the OS should just leave it alone and not try to decode it.
syncsynchalt 6 days ago [-]
The OS treats strings as a blob, yes, but typically specifies that they're a blob of nul-terminated data.
Unfortunately some text encodings (UTF-16 among them) use nuls for codepoints other than U+00. In fact UTF-16 will use nuls for every character before U+100, in other words all of ASCII and Latin-1. Therefore you can't just support _all_ text encodings for filenames on these OSes, unless the OS provides a second syscall for it (this is what Windows did since they wanted to use UTF-16LE across the board).
I've only mentioned syscalls in this, in truth it extends all through the C stdlib which everything ends up using in some way as well.
codedokode 3 days ago [-]
You should not be passing file names in different encodings because other apps won't be able to display them properly. There should be one standard encoding for file names. It would also help with things like looking up a name ignoring case and extra spaces.
syncsynchalt 2 days ago [-]
I mean, I agree there _should_ be one standard encoding, but the Unix API (to pick the example I'm closest to) predates these nuances. All it says is that filenames are a string [of bytes] and can't contain the bytes '/' or '\0'.
It is good for an implementation to enforce this at some level, sure. MacOS has proved features like case insensitivity and unicode normalization can be integrated with Unix filename APIs.
1718627440 6 days ago [-]
You're right I missed that. Sounds like blob size should be communicated out of band.
codedokode 3 days ago [-]
File name is not a blob because it is entered by the user as a text string and displayed for the user as a text string and not as a bunch of hex digits. Also, it cannot contain some characters (like slash or null) so it's not a blob anyway.
And you should be using one specified encoding for file names if you want them to be displayed correctly in all applications. It would be inconvenient if different applications stored file names in different encodings.
For the same reason, encoding should be specified in libraries documentation for all functions accepting or returning strings.
hypeatei 9 days ago [-]
UTF-16 will be quite the mountain as Windows APIs and web specifications/engines default to it for historical reasons.
int_19h 9 days ago [-]
It's not just Windows and JavaScript. On Apple platforms, NSString is UTF-16. On Linux, Qt uses UTF-16 strings. Looking at languages, we have Java (which is where JS got this bug from) and C# both enshrining it in their respective language specs.
So it's far more pervasive than people think, and will likely be in the picture for decades to come.
account42 8 days ago [-]
Qt could really change if they wanted to and really should have by now - it's not like they keep long-term backwards compatibility anyway unlike the others that you mentioned.
Of course they chose to integrate JavaScript so that's less likely now.
electroly 9 days ago [-]
ICU (International Components for Unicode, the library published by the Unicode folks) itself uses UTF-16 internally, and most of these things are built on ICU. I agree strongly with your conclusion--UTF-16 isn't going anywhere. I don't think the ICU people are even talking about changing the internals to UTF-8.
jeberle 9 days ago [-]
UTF-16 arguably is Unicode 2.0+. It's how the code point address space is defined. Code points are either 1 or 2 16-bit code units. Easy. Compare w/ UTF-8 where a code point may be 1, 2, 3, or 4 8-bit code units.
UTF-16 is annoying, but it's far from the biggest design failure in Unicode.
account42 8 days ago [-]
We can argue about "biggest" all day long but UTF-16 is a huge design failure because it made a huge chunk of the lower Unicode space unusable, thereby making better encodings like UTF-8 that could easily represent those code points less efficient. This layer-violating hack should have made it clear that UTF-16 was a bad idea from the start.
Then there is also the issue that technically there is no such thing as UTF-16, instead you need to distinguish UTF-16LE and UTF-16BE. Even though approximately no one uses the latter we still can't ignore it and have to prepend documents and strings with byte order markers (another wasted pair of code points for the sake of an encoding issue) which mean you can't even trivially concatenate them anymore.
Meanwhile UTF-8 is backwards compatible with ASCII, byte order independent, has tons of useful properties and didn't require any Unicode code point assignments to achieve that.
The only reason we have UTF-16 is because early adopters of Unicode bet on UCS-2 and were too cheap to correct their mistake properly when it became clear that two bytes wasn't going to be enough. It's a dirty hack to cover up a mistake that should have never existed.
anonymars 8 days ago [-]
> The only reason we have UTF-16 is because early adopters of Unicode bet on UCS-2 and were too cheap to correct their mistake properly
That's a strange way to characterize years of backwards compatibility to deal with
There are many OS interfaces that were deprecated after five years or even longer. It's been multiple times those five years since then and we'll likely have to deal with UTF-16 for much longer still. Having to provide backwards compatibility for UTF-16 interface doesn't mean they had to keep these as the defaults or provide new UTF-16 interfaces. In particular WIN32 already has 8-bit char interfaces that Microsoft could have easily added UTF-8 support to right then and re-blessed as the default. The decision not to do that was not a technical one but a political one.
anonymars 7 days ago [-]
This isn't "deprecate a few functions" -- it's basically an effort on par with migrating to Unicode in the first place.
I disagree you could just "easily" shove it into the "A" version of functions. Functions that accept UTF-8 could accept ASCII, but you can't just change the semantics of existing functions that emit text because it would blow up backwards compatibility. In a sense it is covariant but not contravariant.
And now, after you've gone through all of this effort: what was the actual payoff? And at what cost if maintaining compatibility with the other representations?
adgjlsfhk1 9 days ago [-]
UTF-16 is the worst of all worlds. Either use UTF32 where code-points are fixed, or if you care about space efficiency use UTF8
mort96 8 days ago [-]
UTF-32 is arguably even more worst of all worlds. You don't get fixed-size units in any meaningful way. Yes you have fixed sized code points, but those aren't the "units" you care about; you still have variable size grapheme clusters, so you still can't do things like reversing a string or splitting a string at an arbitrary index or anything else like that. Yet it consumes twice the space of UTF-16 for almost everything, and four times the space of UTF-8 for many things.
UTF-32 is the worst of all worlds. UTF-16 has the teeny tiny advantage that pure Chinese text takes a bit less space in UTF-16 than UTF-8 (typically irrelevant because that advantage is outweighed by the fact that the markup surrounding the text takes more space). UTF-8 is the best option for pretty much everything.
As a consequence, never use UTF-32, only use UTF-16 where necessary due to backwards compatibility, always use UTF-8 where possible.
kbolino 8 days ago [-]
In order to implement grapheme cluster segmentation, you have to start with a sequence of Unicode scalars. In practice, that means a sequence of 32-bit integers, which is UTF-32 in all but name. It's not a good interchange format, but it is a necessary intermediate/internal format.
There's also the problem that grapheme cluster boundaries change over time. Unicode has become a true mess.
mort96 8 days ago [-]
Yeah, you need some kind of sequence of Unicode scalars. But there's no reason for that sequence to be "a contiguous chunk of memory filled with 32-bit ints" (aka a UTF-32 string); it can just as well be an iterator which operates on an in-memory UTF-8 string and produces code points.
jcranmer 9 days ago [-]
> It's how the code point address space is defined.
Not really. Unicode is still fundamentally based off of the codepoints, which go from 0 to 2^16 + 2^20, and all of the algorithms of Unicode properties operate on these codepoints. It's just that Unicode has left open a gap of codepoints so that the upper 2^20 codepoints can be encoded in UTF-16 without risk of confusion of other UCS-2 text.
jeberle 8 days ago [-]
You forgot `- 2^11` for the surrogate pairs. Gee, why isn't Unicode 2^21 code points? To understand the Unicode code point space you must understand UTF-16. The code space is defined by how UTF-16 works. That was my initial point.
jcranmer 8 days ago [-]
If you're going to count the surrogate pairs as not-a-Unicode-codepoint, you should also count the other noncharacters: the last two codepoints on each of the 17 planes and the range U+FDD0-U+FDEF.
The expansion of Unicode beyond the BMP was designed to facilitate an upgrade compatibility path from UCS-2 systems, but it is extremely incorrect to somehow equate Unicode with UTF-16.
kbolino 8 days ago [-]
FWIW there is an official term for "code points excluding surrogates", it is "Unicode scalar value".
jeberle 8 days ago [-]
OK, I'm lost here. Why is there a 1:1 correspondence between the two?
welferkj 8 days ago [-]
UTF-8 is superior simply because you can trivially choose to parse it as ascii and ignore all the weird foreign bytes.
augustk 8 days ago [-]
> Now just UTF-16 and non '\n' newline types remaining to go
Also ISO 8601 (YYYY-MM-DD) should be the default date format.
dgshsg 9 days ago [-]
We'll have to deal with it forever in network protocols. Thankfully that's rather walled off from most software.
newpavlov 9 days ago [-]
As well as in a number of widely spread cryptographic algorithms (e.g. SHA-2), which use BE for historic reasons.
NooneAtAll3 9 days ago [-]
just call it 2-AHS and you're done :)
delduca 9 days ago [-]
Good call out, I have just removed some #ifdef about endianness from my engine.
mort96 9 days ago [-]
I have some places in some software where I assume little endian for simplicity, and I just leave in a static_assert(std::endian::native == std::endian::little) to let future me (or future someone else) know that a particular piece of code must be modified if it is ever to run on a not-little-endian machine.
account42 8 days ago [-]
In an ideal world you could just write endian-independent code (i.e. read byte by byte) and leave the compiler optimizer to sort it out. This has the benefit of also not tripping up any alignment restrictions.
mort96 8 days ago [-]
Here's my most recent use case:
I have a relatively large array of uint16_t with highly repetitive (low entropy) data. I want to serialize that to disk, without wasting a lot of space. I run compress2 from zlib on the data when serializinsg it, and decompress it when deserializing. However, these files make sense to use between machines, so I have defined the file format to use compressed little endian 16-bit unsigned ints. Therefore, if you ever want to run this code on a big-endian machine, you need to add some code to first flip the bytes around before compressing, then flipping them back after decompressing.
You're right that when your code is iterating through data byte for byte, you can write it in an endian-agnostic way and let the optimizer take care of recognizing that your shifts and ORs can be replaced with a memcpy on little-endian systems. But it's not always that simple.
On the userland side, there is some good progress of using thunking to run 32-bit Windows programs in Wine on Linux without the need for 32-bit libraries (the only edge case remaining is thunking 32-bit OpenGL which is lacking needed extensions for acceptable performance). But the same can't be said for a bunch of legacy 32-bit native Linux stuff like games which commonly have no source to rebuild them.
May be someone can develop such thunking for legacy Linux userland.
eric__cartman 9 days ago [-]
How many of those legacy applications where the source is not available actually need to run natively on a modern kernel?
The only thing I can think of is games, and the Windows binary most likely works better under Wine anyways.
There are many embedded systems like CNC controllers, advertisement displays, etc... that run those old applications, but I seriously doubt anyone would be willing to update the software in those things.
shmerl 9 days ago [-]
Yeah, games I'd guess is the most common case or at least one enough people would care about.
snarfy 8 days ago [-]
I run a game server running a 32bit binary from 2004. I guess I will not be upgrading in the future.
cwzwarich 9 days ago [-]
It shouldn’t be difficult to write a binary translator to run 32-bit executables on a 64-bit userspace. You will take a small performance hit (on top of the performance hit of using the 32-bit architecture to begin with), but that should be fine for anything old enough to not be recompiled.
Fulgen 9 days ago [-]
In some ways, Windows already does that too - the 32-bit syscall wrappers [switch into a 64-bit code segment](https://aktas.github.io/Heavens-Gate) so the 64-bit ntdll copy can call the 64-bit syscall.
shmerl 9 days ago [-]
I would guess so, but I haven't seen anyone developing that so far.
9 days ago [-]
5- 9 days ago [-]
most of those games would have windows builds?
that said, i sometimes think about a clean-room reimplementation of e.g. the unity3d runtime -- there are so many games that don't even use native code logic (which still could be supported with binary translation via e.g. unicorn) and are really just mono bytecode but still can't be run on platforms for which their authors didn't think to build them (or which were not supported by the unity runtime at the time of the game's release).
shmerl 9 days ago [-]
> most of those games would have windows builds?
Yeah, that's a reasonable workaround, as long as it doesn't hit that OpenGL problem above (now it mostly affects DX7 era games, since they don't have Vulkan translation path). Hopefully it can be fixed.
xeonmc 9 days ago [-]
Perhaps a new compatibility layer, call it LIME -- LIME Is My Emulater
ninkendo 9 days ago [-]
LIME Isn’t Merely an Emulator
dontlaugh 9 days ago [-]
In practice, the path for legacy software on Linux is Wine.
majorchord 9 days ago [-]
I have heard people say the only stable ABI on Linux is Win32.
hinkley 9 days ago [-]
Win32S but the other way around.
Win64S?
greatgib 9 days ago [-]
It's the end of an area, Linux used to be this thing that was running on quite anything and allowing to salvage old computers.
I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore.
Now Linux will be in the same lane as osx and windows running after the last shiny new things, and being like: if you want it, buy a new machine that will support it.
arp242 9 days ago [-]
You can still run an older kernel. There are the "Super-long-term support" releases that have 10+ year support cycles. Some distros may go even further.
If you install 6.12 today (via e.g. Debian 13) then you'll be good until at least 2035. So removing it now de-facto means it will be removed in >10 years.
And as the article explains, this mostly concerns pretty old systems. Are people running the latest kernel on those? Most of the time probably not. This is really not "running after the last shiny thing". That's just nonsensical extreme black/white thinking.
threatripper 9 days ago [-]
Won't these super old kernels basically turn into forks after some time that are maintained and even extended for special purposes?
creshal 8 days ago [-]
From a developer's perspective, yes.
From a user's perspective, they just keep working.
account42 8 days ago [-]
That's assuming your old machines will never need to interface with new peripherals or new network protocols or new filesystems or anything that could require changes only found in newer kernels. It's not far removed from saying that Windows still supports them as well because you can always use Windows ME for the rest of the millennium.
Dylan16807 9 days ago [-]
Desktops and laptops from 10 to 15 years ago are basically all 64 bit. By the time this removal happens, we'll be at 20 years of almost all that hardware being 64 bit. By the time hardware becomes "retro", you don't need the latest kernel version.
Lots of distros already dropped 32 bit kernel support and it didn't cause much fuss.
account42 8 days ago [-]
20 years isn't all that much though. We maintain houses for much longer than that so why should we accept such low lifetimes for computers.
leoedin 8 days ago [-]
Because they're fundamentally different things? A house is a machine for providing weather protection. The difference between a modern house and an old one is pretty minor. A computer is a machine for doing calculations. The difference between a modern computer and an old one is - by more or less any metric you can think of - many orders of magnitude. Calculations per Watt, calculations per second, calculations per unit volume etc.
It's not even like we're breaking them. This is just the maintainers of the Linux kernel choosing to not spend their time maintaining compatibility with the old architectures.
Dylan16807 8 days ago [-]
You can put in parts and effort to maintain older computers, but when you can buy a brand new desktop for $120 or a few year old one for $40 and they blow it out of the water on performance and power efficiency, what's the reason to do so? (I'm asking in the context of a main computer, not something to run old games natively or be nostalgic about.)
A computer you buy today will be much more viable in 20+ years than a 20+ year old computer is right now. We were still in the extreme part of speed and density growth back than, and it will lessen every decade.
Mashimo 8 days ago [-]
You might still be able to install linux, just not with the latest kernel.
IshKebab 8 days ago [-]
One of the dumbest things I've heard today...
Houses are obviously very different to computers. Do you also demand 20 year lifetimes for your socks?
mananaysiempre 8 days ago [-]
Ten- or fifteen-year-old hardware is still perfectly serviceable now for some modern applications. (The decade-long Intel monopoly drought of 5% generational improvements to CPU performance has a great deal to do with that.) So this is not as strong of an argument as the same sentence would be if it were said ten years ago.
Dylan16807 8 days ago [-]
It's a plenty strong statement because all that hardware and more is included, back to years before the drought. 64 bit support goes all the way back to some Pentium 4s, including all the dual core models.
greatgib 8 days ago [-]
I'm quite sure that still a few years after 2020 there were still atom or Celeron processors powered laptop that did not support 64 bits.
Maybe it is not that the architecture was not compatible as much as it was restricted or limited by Intel and co for these cpus
creshal 8 days ago [-]
> I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore.
For mainstream laptops/desktops, the 32 bit era ended around 2006 (2003, if you were smart and using Athlon 64s instead of rancid Pentium 4).
Netbooks and other really weak devices held out a few years longer, but by 2010, almost everything new on the market, and a good chunk of the second-hand market, was already 64 bits.
markjenkinswpg 7 days ago [-]
In my experience, the 10-15 year old salvaged computer that still works okay with GNU/Linux is increasingly a 64 bit machine.
Case in point, I'm writing on a x86_64 laptop that was a free give away to me about a year ago with a CPU release year that is 2012.
I have personally given away a x86_64 desktop unit years ago that was even older, might have had DDR1 memory.
Circa 2013 my old company was gifted a x86_64 motherboard with DDR2 memory that ended up serving as our in-office server for many years. We maxed the RAM (8GB) and at some point bought a CPU upgrade on ebay that gave us hardware virtualization extensions.
octoberfranklin 9 days ago [-]
The Apple Watch has 32-bit memory addressing (and 64-bit integer arithmetic -- it's ILP32). Granted it doesn't run Linux, but it's a very very modern piece of hardware, in production, and very profitable.
Same for WASM -- 32-bit pointers, 64-bit integers.
Both of these platforms have a 32-bit address space -- both for physical addresses and virtual addresses.
Ripping out support for 32-bit pointers seems like a bad idea.
mrpippy 9 days ago [-]
With watchOS 26, S9/10 watches will be going to normal ILP64 ARM64.
RAM limitations were one reason to use arm64_32, but a bigger reason is that the first watches were only ARMv7 (32-bit) so by sticking with 32-bit pointers, Apple was able to statically recompile all the 3rd party (ARMv7) apps from LLVM bitcode to arm64_32.
64-bit memories are already in wasm 3.0 draft (and in any case this isn't a platform where you'd need the Linux kernel running).
SAI_Peregrinus 8 days ago [-]
WASM isn't being used to run the Linux kernel, it's run by an application on top of an OS. That OS can be 64-bit, the WASM VMs don't care.
9 days ago [-]
jacquesm 9 days ago [-]
Funny, I remember 32 bits being 'the future', now it is the distant past. I think they should keep it all around, and keep it buildable. Though I totally understand the pressure to get rid of it I think having at least one one-size-fits-all OS is a very useful thing to have. You never know what the future will bring.
justin66 9 days ago [-]
There's always NetBSD. I'm pretty sure that's supporting x86 as far back was 80486 and 32-bit SPARC as far back as... something I wouldn't want to contemplate.
nektro 8 days ago [-]
important to remember that this fate isn't going to happen again with 64bit
petcat 9 days ago [-]
Just because support would be removed from current and new versions doesn't mean the old code and tarballs are just going to disappear. Can dust off an old 32 bit kernel whenever you want
SlowTao 9 days ago [-]
Always to option to fork it. Linux Legacy? Linux 32? Linux grey beard!
smitty1e 9 days ago [-]
Technologies have lifecycles. Film at 11.
Mathnerd314 9 days ago [-]
Linux has become the dominant operating system for a wide range of devices, even though other options like FreeRTOS or the BSD family seem more specialized. The widespread adoption of Linux suggests that a single, versatile operating system may be more practical than several niche ones. However, the decision to drop support for certain hardware because it complicates maintenance, as seen here, would seem to contradict the benefit of a unified system. I wouldn't be surprised if it really just results in more Linux forks - Android is already at the point of not quite following mainline.
charcircuit 9 days ago [-]
>Android is already at the point of not quite following mainline.
It follows the latest LTS which I think is reasonable especially since phone vendors wants to have support for the device for several years.
shasheene 8 days ago [-]
I think this is premature and a big mistake for Linux.
The costs of distros and the kernel steadily dropping older x86 support over the last few years never causes an outcry but it's an erosion of what made Linux great. Especially for non-English speaking people in less developed countries.
Open-source maintenance is not a obligation, but it's sad there is not more people pushing to maintain support. Especially for the "universal operating system" Debian which was previously a gold standard in architecture support.
I maintain a relatively popular live Linux distro based on Ubuntu and due to user demand will look into a NetBSD variant to continue support (as suggested in this thread), potentially to support legacy 586 and 686 too.
Though a Debian 13 "Trixie" variant with a custom compiled 686 kernel will be much easier than switching to NetBSD, it appears like NetBSD has more commitment to longer-term arch support.
It would be wonderful to develop systems (eg emulation) to make it practical to support architectures as close to indefinitely as possible.
It does feel like a big end of an era moment for Linux and distros here, with the project following the kind of decision making of big tech companies rather than the ideals of computer enthusiasts.
Right now these deprecation decisions will directly make me spend time working at layers of abstraction I wasn't intending to in order to mitigate the upstream deprecations of the kernels and distros. The reason I have used the kernel and distros like Debian has been to offload that work to the specialist maintainers of the open-source community.
meisel 9 days ago [-]
It seems like it takes just one user using a certain piece of hardware to justify it being supported in the kernel, which is surprising to me. The cost to kernel dev velocity is not weighed more heavily against that?
bjackman 8 days ago [-]
In general I don't think the marginal benefit of removing support for a certain piece of hardware would be significant in most cases. Most of the kernel is generic across a broad enough spectrum that removing one slice of that spectrum isn't likely to change its breadth.
E.g. there's some stuff like erratum workarounds for old x86 CPUs that would be nice to drop, but they are part of a big framework for handling x86 diversity. Dropping individual workarounds doesn't let you drop the framework.
Exceptions are gonna be cases where dropping the support removed something significant from the lowest common denominator. Big stuff like word size, memory ordering (I assume dropping Alpha would be quite handy), virtual address space limitations.
SAI_Peregrinus 8 days ago [-]
One known user. Linux doesn't have automatic telemetry in every distro (or even most distros), the kernel devs don't really know how many people use. So if they know of one user, there are probably more users that just haven't come to their attention on the mailing lists.
hamandcheese 8 days ago [-]
Sometimes, supporting special use cases like this can be a valuable exercise since it shows you all the places in your project that you made assumptions without even realizing it. It seems plausible to me that supporting niche users improves quality of the project as a whole.
kstrauser 8 days ago [-]
To a point, yeah. Adding BE support to my (userspace) code revealed some bugs that affected LE, too. Oops! But you can take that too far, too. Like, go ahead and assume power-of-two aligned byte sizes. If someone wants to make an 11 bit byte, let them handle that in their own non-upstreamed fork. No user code’s going to work right on it anyway.
You can be so flexible that it turns everything into a giant slog. I doubt 32 bit support is anywhere near that horrid; commenting on the idea more than this specific case.
EVa5I7bHFq9mnYK 9 days ago [-]
Aren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.
em3rgent0rdr 9 days ago [-]
Not just more power-efficient, but also a little more memory efficient because pointers are only half as big and so don't take up as much space in the cache. Lower-bit chips are also smaller (which could translate into faster clock and/or more functional units per superscaler core and/or more cores per die).
Part of the problem with these discussion is that often when people say "64-bit" vs "32-bit" they are also considering all the new useful instructions that were added to the new instruction set generation. But a true "apples-to-apples" comparison between "32-bit" and "64-bit" should be using almost identical whose only difference is the datapath and pointer size.
I feel that the programs and games I run shouldn't really need more than 4GB memory anyway, and the occasion instance that the extra precision of 64-bit math is useful could be handled by emulating the 64-bit math with the compiler adding a couple extra 32-bit instructions.
kbolino 9 days ago [-]
Applications don't get 4GB with a 32-bit address space. The practical split between application and kernel was usually 1-3 or 2-2 with 3-1 being experimental and mooted with the switch to 64-bit. Nowadays with VRAM being almost as large as main RAM, you need the larger address space just to map a useful chunk of it in.
When you factor in memory fragmentation, you really only had a solid
0.75-1.5GB of space that could be kept continuously in use. That was starting to become a problem even when 32-bit was the only practical option. A lot of games saw a benefit to just having the larger address space, such that they ran better in 64-bit with only 4GB of RAM despite the fatter 64-bit pointers.
monocasa 9 days ago [-]
It depends on the kernel architecture. 4G/4G kernels weren't the most common thing, but also weren't exactly rare in the grand scheme of things. PowerPC macOS (and x86 in macOS before they officially released Intel based mac hardware) were 4G/4G for example. The way that works under x86 is that you just reserve a couple kernel pages mapped into both address spaces to do the page table swap on interrupts and syscalls. A little expensive, but less than you'd think, and having the kernel and user space not fight for virtual address space provided its own efficiencies to partially make up the difference. We've been moving back to that anyway with Kernel Page Table isolation for spectre mitigations.
And 3-1 wasn't really experimental. It was essentially always that way under Linux, and had been supported under Windows since the late 90s.
kbolino 8 days ago [-]
Yeah, "experimental" may not be the right word, but actually getting to use the 3-1 split required all of the following: at least 3GB of physical RAM (obviously), the O/S booted with /3GB flag, and the application in question linked with /LARGEADDRESSAWARE flag (and not mishandling the high bit of a pointer). Many video games towards the end of the 32-bit era were built this way tbf, though they still generally do better on 64-bit Windows/Wine anyway.
vlovich123 9 days ago [-]
I believe that's an accident of the evolutionary path chosen with syscalls. If we'd instead gone with a ring buffer approach to make requests, then you'd never need to partition the memory address space; the kernel has its memory and userspace has its and you don't need the situation where the kernel is always mapped.
kbolino 9 days ago [-]
Hmm. I don't understand how that would work.
I think it would be possible for e.g. microkernels to greatly reduce the size of the reservation (though not to eliminate it entirely). However, I can't imagine how you would handle the privilege escalation issue without having at least some system code in the application's virtual address space that's not modifiable by the application.
vlovich123 9 days ago [-]
I'm not sure how privilege escalation would be an issue since you'd never escalate privilege in the first place (I'm assuming you're talking about CPU ring privileges and not OS privileges). You'd just enqueue into the shared kernel/user space ring buffer your operations and the kernel would pick them up on its side, but you'd never jump between rings.
Such a design may require at least one processor dedicated to running the kernel at all times, so it might not work on a single processor architecture. However, single processor architectures might be supportable by having the "kernel process" go to sleep by arming a timer and the timer interrupt is the only one that's specially mapped so it can modify the page table to resume the kernel (for handling all the ring buffers + scheduling). As you note, there's some reserved address space but it's a trivial amount just to be able to resume running the kernel. I don't think it has anything to do with monolithic vs microkernels.
adgjlsfhk1 9 days ago [-]
I have for a while wondered why we don't have "security core"s that are are really slow, but don't have caches or speculative execution so you can run security critical code without having to worry about CPU timing attacks
adwn 8 days ago [-]
I think that would be of little help if the faster, less-secure cores have access to the same memory system as the secure cores. If the JavaScript engine of your browser runs on the fast cores, and you're visiting a malicious website, then vulnerabilities due to speculative execution on the fast cores could still leak information that was written by the slow cores. And you really wouldn't want to run the JS engine on cores without caches and speculative execution, at least not for everyday browsing.
kbolino 8 days ago [-]
What problem are you trying to solve?
If you just want constant-time operations, you just need dedicated instructions. Maybe they run on dedicated cores, but that's an implementation detail. I think this is a good idea, and it feels like we're heading this way already, more or less.
If you want to address all of the vulnerabilities that have arisen, you need full isolation. As mentioned in a sibling comment, you can't share any memory or caches etc. Each "security core" would have to be fully isolated from every other core, including every other security core. And you also need to segregate out "sensitive" code and data from non-sensitive code and data. When all is said and done, I don't see how we're talking about anything less than scrapping all existing ISAs, and perhaps even von Neumann architecture itself. I'm sure there are some middle-ground solutions between where we are today and this extreme, but I think they're going to look more like TPM/Secure Enclave than special cores, and they're only going to partially address the vulnerabilities.
vlovich123 8 days ago [-]
You don’t really need a security core with my proposal. By ensuring that kernel and userspace code run in completely different page table domains, it removes the possibility for a meltdown style attack precisely because the memory was mapped alongside userspace and relied on CPU protections to keep it secret (those protections got thwarted by speculative execution). It’s actually a software design flaw.
kbolino 9 days ago [-]
True, you don't have to go full microkernel just to have messages passed though a buffer. However, if the buffer is shared by all processes, it does need to have some protection. I guess you could assign one buffer per process (which might end up using a lot of physical RAM), and then just crash the process if it corrupts its own buffer. The bigger issue with this approach might be adapting to asynchrony though.
vlovich123 9 days ago [-]
It wouldn't be by all processes. One per process just like with io_uring. Not sure how it would end up being all that much physical RAM - you get a lot more memory mapped when you just start a process. Page faults might be another tricky corner case.
yjftsjthsd-h 9 days ago [-]
I wish x32 had taken off; better performance and lower memory use.
I have a netbook that would really benefit from that. It's a 64-bit Atom processor. Currently I'm running a 32-bit kernel and userspace, but it looks like the way forward is going to be 64-bit kernel and 32-bit userspace.
kimixa 9 days ago [-]
On anything but the smallest implementations, the 32 vs 64bit alu cost difference is pretty tiny compared to everything else going on in the core to get performance. And assumes the core doesn't support 32-bit ops, leaving the rest of the ALU idle, or does something like double pumping.
Really the ALU width is an internal implementation detail/optimisation, you can tune it to the size you want at the cost of more cycles to actually complete the full width.
octoberfranklin 9 days ago [-]
It's the MMU width, not the ALU width, that matters.
Lots of machines are capable of running with 32-bit pointers and 64-bit integers ("Knuth mode" aka "ILP32"). You get a huge improvement in memory density as long as no single process needs more than 4GB of core.
kimixa 9 days ago [-]
I assume you mean "pointer width" - ala the x32 ABI and similar, and more about cache use than "Switching Transistor Count".
But really that's a software/OS level thing, and though the benefits have definitely been shown, the seem small enough to not be worth the upheaval.
Though possibly related, larger pages have been shown to have significant speedups without changing the ABI (as much, at least mmap() and similar will have slightly different specifics). IMHO the only possible "benefit" to 4kb page sizes is to (ab)use it to trap things like array overruns - though using that is a poor substitute for /real/ bounds checking - a lot can go wrong within 4kb, after all.
ainiriand 9 days ago [-]
What makes you think that a 32 bit system has 32 transistors? For example, from the top of my head, the pentium pro had a 86 bit direction bus and a 64 bit data bus.
bobmcnamara 9 days ago [-]
Sometimes you gotta run real fast and go right to bed to save power.
creshal 8 days ago [-]
Memory buses are negligible, compared to everything else going on. Especially in a SoC that has not just a CPU, but 20 other devices as well.
chasil 8 days ago [-]
Solaris uses 32-bit binaries in /bin and /usr/bin for most of POSIX.2, even though it requires the x86-64 architecture.
I saw this last in SmartOS.
smallpipe 9 days ago [-]
Wait until you hear about 8 bit systems
em3rgent0rdr 9 days ago [-]
Yes and no. A problem with 8-bit and 16-bit for desktop and servers is the limited memory address space, so the compiler has to insert extra instructions to deal with things like updating the segment registers. And likewise if you need to do higher-bit math then the compiler again has to insert extra instructions. Those extra instructions clog up the pipeline, but aren't needed if your largest program's working memory set and the largest precision math you generally need fits within the ISA's bit size. Unless you are doing scientific computing or other large-memory set tasks like Blender (which dropped 32-bit support), then 32-bit really is good-enough.
I couldn't tell if your comment was a joke, but it is worth mentioning the 8-bit microcontrollers like TinyAVR still fill a niche where every joule and cent counts.
theshrike79 8 days ago [-]
Compared to 64 bit? Maybe.
Compared to ARM-based systems? Nope.
ry6000 9 days ago [-]
I can’t help but wonder if kernel devs realize how much this discussion sounds like something you’d expect from Apple. They are talking about obsoleting hardware not because it’s fundamentally broken, but because it no longer fits neatly into a roadmap. Open source has always been about making hardware outlive commercial interest and let it run long after the hardware vendor abandons it.
I'm pretty shocked to see comments like "the RAM for a 32-bit system costs more than the CPU itself", but open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running.
I understand that maintainers don’t want to drag around unmaintained code forever, and that testing on rare hardware is difficult. But if the code already exists and is working, is it really that costly to just not break it? The kernel's history is full of examples where obscure architectures and configs were kept alive for decades with minimal intervention. Removing them feels like a philosophical shift, especially when modern hardware is more locked down and has a variety of black box systems running behind it like Intel ME and AMD PSP.
kergonath 9 days ago [-]
> They are talking about obsoleting hardware not because it’s fundamentally broken, but because it no longer fits neatly into a roadmap.
Not really. The discussion is about cost, benefits and available resources. Projects are not immune because they are open source or free software. Actual people still need to do the work.
> Open source has always been about making hardware outlive commercial interest and let it run long after the hardware vendor abandons it.
Again, not really. Open source has always been all about freely modifying and distributing software. This leaves some freedom for anyone to keep supporting their pet hardware, but that’s a consequence. In this case, I don’t think it would be a real problem if anyone would step up and commit the ressources necessary to keep supporting older hardware. This freedom was not taken away because a project’s developers decided that something was not worth their time anymore.
jcranmer 9 days ago [-]
> But if the code already exists and is working, is it really that costly to just not break it?
It depends on the feature, but in many cases the answer is in fact 'yes.' There's a reason why Alpha support (defunct for decades) still goes on but Itanium support (defunct for years) has thoroughly been ripped out of systems.
Teknoman117 9 days ago [-]
An interesting example of this was i386 support (as in being able to run on the 80386) being removed way back in kernel 3.8 (early 2013). If you can support 80486 why can't you support 80386?
Well, there really wasn't much support for atomic instructions in x86 before the introduction of compare-exchange in the 486. Any time you wanted guaranteed atomicity on a 386 you had to disable interrupts, which among other things means that if you lock up during a critical section your entire system hangs. Another implication is that nearly all of our lockless data structure constructs depend on compare-exchange instructions.
It vastly simplified some very tricky sections of the kernel to remove support for systems that don't have hardware atomic instructions, so it ended up being done.
kstrauser 9 days ago [-]
What's the Venn diagram of people stuck with 32-bit hardware and people needing features of newer kernels? Existing kernels will keep working. New devices probably wouldn't support that ancient hardware; seen any new AGP graphics cards lately?
There's not a compelling reason to run a bleeding edge kernel on a 2004 computer, and definitely not one worth justifying making the kernel devs support that setup.
9 days ago [-]
Palomides 9 days ago [-]
security isn't a compelling reason?
kstrauser 9 days ago [-]
The bulk of CVEs that crossed my desk in the last couple of years were in things that wouldn’t matter on a 32-bit system, like problems in brand new graphics cards or fibre channel or 10G Ethernet, or KVM hosting, or things like that. There wasn’t a huge flood of things affecting older, single-user type systems.
But in any case, I’m sure Red Hat etc would be happy to sell backports of relevant fixes.
It’s not that I’m unsympathetic to people with older systems. I get it. I’ve got old hardware floating around that I’ve successfully kept my wife from ecycling. It’s that I’m also sympathetic to the kernel devs who only have so many hours, and don’t want to use them supporting ancient systems that aren’t still widely used.
michaelt 9 days ago [-]
If I'm running a living museum of computer history, to let the youth of today experience 15" CRTs and learn the difference between ISA, PCI and AGP slots - I'm probably not connecting my exhibits to the internet.
wolrah 8 days ago [-]
> security isn't a compelling reason?
For legacy hardware like this it's usually not anywhere close to as important as it is for modern systems.
These systems are not being used to browse the modern web, they're too slow.
They're not being used to host production multiuser environments beyond a few retrocomputing homelabbers' toy systems, where the worst case scenario is a restore from backup and banning a user or two rather than data loss/breach and/or legal action.
The ones still in actual active use are almost all appliance systems that mostly haven't seen a kernel update in years or ever because they are usually exist to go with some piece of hardware that never got an in-tree driver and thus can't work with anything much newer than what it shipped with and/or some software that depends on ancient libraries no distro ships anymore. These systems don't need to (and shouldn't) be exposed to untrusted networks, users, or content, they can (and already should) be locked down by a skilled admin to only communicate with the minimum number of systems needed for whatever purpose they serve. If the admin isn't sufficiently skilled to confidently handle that, the system and admin should both be replaced.
---
I have an old IBM PS/2 that's my family's first computer, which still has its original Windows 3.1 install on it. I imaged the original hard drive and moved it to a CF card, but that also means I can screw around with it and not worry about breaking anything because I can just restore the last known good image. I don't connect it to the internet often but if on one of those rare times I happened to somehow stumble upon someone who had been saving a drive-by exploit for IE 3.0 or a RCE against Trumpet Winsock that then infected my system I'd just do the same. Anything this old is small enough to be imaged easily.
davidkwast 9 days ago [-]
"perfection"
margalabargala 9 days ago [-]
> open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running.
Ehhh, it's about users having the ability to run whatever they like. Which they do.
If a group of users of 32 bit hardware care to volunteer to support the latest kernel features, then there's no problem.
If no one does, then why should a volunteer care enough to do it for them? It's not like the old kernel versions will stop working. Forcing volunteers to work on something they don't want to do is just a bad way to manage volunteers.
dwattttt 9 days ago [-]
> If a group of users of 32 bit hardware care to volunteer to support the latest kernel features, then there's no problem.
It's not just the case that you need people to support 32bit/nommu; you also have to account for the impact on other kernel devs working on features that are made harder.
This is called out in the article around keeping highmem support.
ry6000 9 days ago [-]
That is a fair point! I do think though that it would make sense for maintainers to at least put out an open call to users and developers before dropping something as fundamental as 32 bit support. The reality is that not all users are going to be kernel developers, and even many developers today aren’t familiar with the workflow kernel development requires. Mailing lists, patch submission processes, and the cultural expectations around kernel work are all a pretty steep barrier to entry, even if someone does care about the removal and also happens to be a developer.
The other dynamic here is that the direction in Linux does come from the top. When you have maintainers like Arnd Bergmann saying they would "like" to remove support for hardware (like the ARM boards), that sets the tone, and other contributors will naturally follow that lead. If leadership encouraged a philosophy closer to "never break existing hardware" the same way we’ve had "never break userspace" for decades, we probably wouldn’t even be debating removing 32 bit.
I’m not saying kernel devs need to carry the weight alone, but it would be nice if the community’s baseline stance was towards preservation rather than obsolescence. :(
johnklos 9 days ago [-]
So Arnd Bergmann thinks that all future systems, embedded included, will have 64 bit CPUs? Or will embedded just stop using Linux and move to the BSDs?
SAI_Peregrinus 9 days ago [-]
Embedded has already split: You've got 8-bit, 16-bit, and some in-between MCUs that never ran Linux in the first place. You've got 32-bit MCUs that never ran Linux in the first place. You've got FPGAs that never really even run software. And you've got "application processors" like the ARM Cortex-A series that get used for "embedded Linux" in some cases. ARM Cortex-A series won't release any more 32-bit ISAs, so that mostly just leaves RISC-V as a potentially-relevant 32-bit ISA that might get new CPU designs. That's a small niche within an already small niche in embedded. Most embedded systems aren't using Linux, they're using an RTOS or bare-metal code.
adgjlsfhk1 9 days ago [-]
8 and 16 bit are dying pretty rapidly. You can make some pretty tiny 32 bit CPUs (e.g. https://github.com/YosysHQ/picorv32 is a RV32 with only a couple thousand transistors). On a budget optimized process node (e.g. 28nm), the core is absolutely tiny and all of the cost comes from the (s)ram.
SAI_Peregrinus 8 days ago [-]
Yeah, I expect them to get relegated to Chip–on–Board (the little black epoxy blobs you'll see in 4-function calculators, cheap multimeters, & the like) ASICs as integrated MCUs and as soft cores in some FPGAs. I'd only go with an 8-bit or 16-bit chip at the extreme end of cost–constrained ultra–high–volume design already, 32-bit MCUs are cheap enough for everything else.
jtolmar 8 days ago [-]
From the article:
> The kernel is still adding support for some 32-bit boards, he said, but at least ten new 64-bit boards gain support for each 32-bit one.
And
> To summarize, he said, the kernel will have to retain support for armv7 systems for at least another ten years. Boards are still being produced with these CPUs, so even ten years may be optimistic for removal. Everything else, he said, will probably fade away sooner than that.
So, no, he does not think that at all.
wibbily 9 days ago [-]
> One other possibility is to drop high memory, but allow the extra physical memory to be used as a zram swap device. That would not be as efficient as accessing the memory directly, but it is relatively simple and would make it possible to drop the complexity of high memory.
Wild, like some kind of virtual cache. Reminds me a bit of the old Macintosh 68k accelerators; sometimes they included their own (faster) memory and you could use the existing sticks as a RAM disk.
chasil 8 days ago [-]
Unfortunately, I am still using a 32-bit kernel using high memory. It was caled "PAE" - physical address extensions.
$ cat /proc/version
Linux version 2.6.18-419.0.0.0.2.el5PAE ... (gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)) #1 SMP Wed Jun 28 20:25:21 PDT 2017
doublepg23 8 days ago [-]
Why? Industrial controller?
natas 9 days ago [-]
the netbsd team agrees! more users for us.
sylware 8 days ago [-]
I have 32 bits support on my x86_64 gaming ring, _ONLY_ for the steam client.
The "steam client" is still a 32 bits ELF executable, which statically loads openGL and x11 libs... (namely not even a wayland->x11 fallback or a opengl->CPU rendering).
We would be all better with a nogfx static PIE executable, even a nogfx dynamic PIE executable if they want to explore the ELF setup of a distro.
datenwolf 8 days ago [-]
> There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.
Ohhh yes!
So, a couple of weeks ago I came across a discussion where some distro (I don't remember which one) contemplated removing 32-bit user space support, suggesting to users to simply run a VM running a 32 bit Linux instead. It was a stupid suggestion then, and this statement is a nice authorative answer from the kernel side, where such suggestions can be shoved to.
chasil 8 days ago [-]
Red Hat has removed i386 multilib in rhel10.
"Linking against 32-bit multilib packages has been removed. The *.i686 packages remain supported for the life cycle of Red Hat Enterprise Linux 9."
Probably SuSE. We use SLES15 at work and their bizarre decisions in SLES 16 to remove X servers (except for XWayland), remove 32-bit libraries, and complete removal of their AutoYaST unattended install tool in favor for a tool that is maybe 25% compatible with existing AutoYaST files still baffles me. We spent months moving to SLES15 from a RHEL derivative a few years ago and now we basically have to do it again for SLES16 with as big as the changes are. We have some rather strong integrations with the Xorg servers, and Wayland won't cut it for us currently, so we're stuck unless we want to rearchitect 20 years of display logic to some paper spec that isn't evenly implemented and when it is, it's buggy as shit.
I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.
webdevver 9 days ago [-]
i do miss being able to read and memorize hex addresses. 64 bits is a little too long to easily 'see' at a glance. or see at all for that matter.
ezoe 8 days ago [-]
It's interesting that only objection for removing big endian is from IBM and their mainframe and PowerPC. Also big endian is restricted to 32bit in Linux kernel.
wltr 8 days ago [-]
I have some 32-bit systems (arm and x86), and it looks like I’m going to use them till the hardware breaks. The old x86 system is power hungry and inefficient, but the thing is, I power it on very occasionally. Like for half a day once a month. So its power consumption isn’t an issue. Probably I should consider some BSD for it. But what should I do with an arm system, if that’s applicable, I have no idea.
shevis 8 days ago [-]
I’m surprised no one is talking about the 2038 problem.
unregistereddev 8 days ago [-]
That is not specific to 32-bit system architectures. The 2038 problem is specific to timestamps that are represented as milliseconds since the Unix epoch and are stored in a 32-bit integer. It's quite possible (and common) to deal with 64-bit integers on a 32-bit system architecture.
I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.
listeria 8 days ago [-]
It's actually seconds since epoch, not milliseconds. Here's a small program to verify it:
date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_'
It is also mentioned in perldoc Time::Piece [1], as a warning for people whose build of perl uses 32-bit integers for time.
It got fixed in the kernel & musl in 2020. It got fixed in glibc in 2021. Everything built against the currently-supported versions of those things will have 64-bit `time_t` since the headers are updated. It mostly only matters for proprietary programs distributed only as binaries that don't get updates, for systems that no longer get updates at all, and for people running computer history museum exhibits. Some distros take a long time to update, but even the longest don't have 17-year support cycles.
I'm sure it'll cause someone some issues, but it'll be very niche by 2038. Most of the sorts of systems that it could cause problems for aren't being used to plan things years in advance, some probably don't even do anything with the date. So it's a niche within a niche (unupdatable systems used for future planning) that's likely to have problems soon, and overall probably no longer a big deal.
TL;DR: It's solved upstream, only an issue for some systems that don't get updates.
stephen_g 9 days ago [-]
This seems pretty uninformed on the embedded side - the speaker is I'm sure very qualified generally but it sounds like mostly on the server/desktop side of things.
Like on Armv7-M it's said "Nobody is building anything with this kind of hardware now" - this is just wrong to the point of ridiculousness. Thousands of new products will be designed using these microcontrollers and still billions of units will be produced with them in them - now, true that almost none of those will run Linux on those MCUs but it's crazy to say "nobody" is building things with them. Many of course are moving to Armv8-M microcontrollers but those are 32 bit too!
On the Linux side, there are things like the AMD/Xillinx Zynq-7000 series that will be supported for many years to come.
It's not the worst idea in the world to deprecate support for 32-bit x86 but it is not time to remove it for ARM for many years yet.
Dylan16807 9 days ago [-]
1. Until proven otherwise, let's assume that the speaker at the Linux conference was probably talking about Linux and saying something not ridiculous.
2. That sentence wasn't about 32-bit, it was about devices without MMUs.
nagamsreekar 9 days ago [-]
[dead]
Rendered at 18:46:17 GMT+0000 (Coordinated Universal Time) with Vercel.
It's not a well argumented thought, just a nagging feeling.
Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings. A system that would allow communication, simple media processing and productivity.
These days it feels like we are at a tipping point for open computing. It feels like being a frog in hot water.
That was part of the plan for Minix 3.
Clean separation in a microkernel, simple enough for teaching students, but robust.
But Intel used it and gave nothing back, and AST retired. :-(
Let's look at the lowest end chip in the discussion. Almost certainly the SAM9x60.... it is a $5 ARMv5 MMU chip supporting DDR2/LPDDR/DDR3/LPDDR3/PSRAM, a variety of embedded RAM and 'old desktop RAM' and mobile RAM.
Yes it's 32-bit but at 600MHz and GBits of RAM support. But you can seriously mass produce a computer under $10 with the chip (so long as you support 4-layer PCBs that can breakout the 0.75mm pitch BGA). As in, the reference design with DDR2 RAM is a 4-layer design.
There are a few Rockchips and such that are (rather large) TQFP that are arguably easier. But since DDR RAM is BGA I think it's safe to assume BGA level PCB layout as a point of simplicity.
---------
Everything smaller than this category of 32-bit / ARMv5 chips (be it Microchip SAM9x60, or competing Rockchips or AllWinner) is a microcontroller wholly unsuitable for running Linux as we know it.
If you cannot reach 64MBs of RAM, Linux is simply unusable. Even for embedded purposes. You really should be using like FreeRTOS or something else at that point.
---------
Linux drawing the line at 64MB hardware built within the last 20 years is.... reasonable? Maybe too reasonable. I mean I love the fact that the SAM9x60 is still usable for modern and new designs but somewhere you have to draw the line.
ARMv5 is too old to compile even like Node.js. I'm serious when I say this stuff is old. It's an environment already alien to typical Linux users.
A $1 Linux capable ARM: https://www.eevblog.com/forum/microcontrollers/the-$1-linux-...
I'd expect that there were even cheaper processors now since it's eight years later.
Fully open hardware, with mainline Linux open source drivers. It's hard to beat SAM9x60 in openness, documentation and overall usability. It's specs are weaker but keeping up with mainline Linux is very, very relevant. Especially in this discussion
Open source is one thing, but open hardware - that’s what we really need. And not just a framework laptop or a system76 machine. I mean a standard 64-bit open source motherboard, peripherals, etc that aren’t locked down with binary blobs.
The problem here is scale. Having fully-open hardware is neat, but then you end up with something like that Blackbird PowerPC thing which costs thousands of dollars to have the performance of a PC that costs hundreds of dollars. Which means that only purists buy it, which prevents economies of scale and prices out anyone who isn't rich.
Whereas what you actually need is for people to be able to run open code on obtainium hardware. This is why Linux won and proprietary Unix lost in servers.
That might be achievable at the low end with purpose-built open hardware, because then the hardware is simple and cheap and can reach scale because it's a good buy even for people who don't care if it's open or not.
But for the mid-range and high end, what we probably need is a project to pick whichever chip is the most popular and spend the resources to reverse engineer it so we can run open code on the hardware which is already in everybody's hands. Which makes it easier to do it again, because the second time it's not reverse engineering every component of the device, it's noticing that v4 is just v3 with a minor update or the third most popular device shares 80% of its hardware with the most popular device so adding it is only 20% as much work as the first one. Which is how Linux did it on servers and desktops.
is this even doable?
Could Amazon or Facebook do this if they just wanted to, e.g. to help break the hold of their competitors on markets they care about? Absolutely.
Could some hobbyist do it? Not on their own, but if you do part of it and someone else does part of it, the whole thing gets done. See e.g. Asahi Linux.
Open hardware you can buy now: https://www.crowdsupply.com/sutajio-kosagi/precursor
The open OS that runs on it: https://betrusted.io/xous-book/
A secret/credential manager built on top of the open hardware and open software: https://betrusted.io
His blog section about it: https://www.bunniestudios.com/blog/category/betrusted/precur...
"The principle of evidence-based trust was at work in our decision to implement Precursor’s brain as an SoC on an FPGA, which means you can compile your CPU from design source and verify for yourself that Precursor contains no hidden instructions or other backdoors. Accomplishing the equivalent level of inspection on a piece of hardwired silicon would be…a rather expensive proposition. Precursor’s mainboard was designed for easy inspection as well, and even its LCD and keyboard were chosen specifically because they facilitate verification of proper construction with minimal equipment."
Which means, "open" has nothing to do with openness. What you want is standardization and commoditization.
There are practically no x86 hardware that require model-specific custom images to boot. There are practically no non-x86 hardware that don't require model-specific custom images to boot. ARM made perceptible amount of efforts in that segment with Arm SystemReady Compliance Program, which absolutely nobody in any serious businesses cares about, and it only concern ARM machines even if it worked.
IMO, one of problems in efforts going in from software side is over-bloated nature of desktop software stacks and bad experiences widely had with UEFI. They aren't going to upgrade RAM to adopt overbloated software that are bigger than the application itself just because that is the new standard.
We'll likely never have "affordable" photolithography, but electron beam lithography will become obtainable in my lifetime (and already is, DIY, to some degree.)
https://www.youtube.com/watch?v=IS5ycm7VfXg
However, making at home a useful microcontroller or FPGA would require not only an electron-beam lithography machine, but also a ion-implantation machine, a diffusion furnace, a plasma-etch machine, a sputtering machine and a lot of other chemical equipment and measurement instruments.
All the equipment would have to be enclosed in a sealed room, with completely automated operation.
A miniature mask-less single-wafer processing fab could be made at a cost several orders of magnitude less than a real semiconductor fab, but the cost would still be of many millions of $.
With such a miniature fab, one might need a few weeks to produce a batch of IC's worth maybe $1000, so the cost of the equipment will never be recovered, which is why nobody does such a thing for commercial purposes.
In order to have distributed semiconductor fabs serving small communities around them, instead of having only a couple of fabs for the entire planet, one would need a revolution in the fabrication of the semiconductor manufacturing equipment itself, like SpaceX has done for rockets.
Only if the semiconductor manufacturing equipment would be the result of a completely automated mass production, which would reduce its cost by 2 or 3 orders of magnitude, affordable small-scale but state-of-the-art fabs would be possible.
But such an evolution is contrary to everything that the big companies have done during the last 30 years, during which all smaller competitors have been eliminated, the production has become concentrated in quasi-monopolies and for the non-consumer products the companies now offer every year more and more expensive models, which are increasingly affordable only for other big companies and not for individuals or small businesses.
Maybe?
Another point of view might be that in a few weeks you could produce a batch of ICs you can actually trust, that would be several orders of magnitude more valuable than the $1000 worth of equivalents from the untrusted global supply chain.
University nanofabs have all of these things today. https://cores.research.asu.edu/nanofab/
> but the cost would still be of many millions of $.
A single set of this equipment is only singular millions today commercially.
Using something like this for prototyping/characterization or small-scale analog tasks is where the real win is.
It is weird that they do not have any ion implantation machine, because there are devices that are impossible to make without it. Even for simple MOS transistors, I am not aware of any other method for controlling the threshold voltage with enough precision. Perhaps whenever they need ion implantation they send the wafers to an external fab, with which they have a contract, to be done there.
Still, I find it hard to believe that all the equipment that they have costs less than 10 million $, unless it is bought second hand. There is indeed a market for slightly obsolete semiconductor manufacturing equipment, which has been replaced in some first tier fabs and now it is available at significant discounts for those who are content with it.
some revolution. still not even on the moon yet
Wafer machines from the 1970s could be fairly cheap today, if there were sufficient demand for chips from the 1970s (~1MHz, no power states, 16 bit if you’re lucky, etc), but that trend would have to stop and reverse significantly for affordable wafer factories for modern hardware to be a thing.
I doubt anyone here has a clean enough room.
https://www.youtube.com/watch?v=PdcKwOo7dmM
Jordan Peterson has entered the building...
https://www.youtube.com/watch?v=qsHJ3LvUWTs
If that comes to pass we will want software that run on earlier nodes and 32bit hardware.
"The principle of evidence-based trust was at work in our decision to implement Precursor’s brain as an SoC on an FPGA, which means you can compile your CPU from design source and verify for yourself that Precursor contains no hidden instructions or other backdoors. Accomplishing the equivalent level of inspection on a piece of hardwired silicon would be…a rather expensive proposition. Precursor’s mainboard was designed for easy inspection as well, and even its LCD and keyboard were chosen specifically because they facilitate verification of proper construction with minimal equipment."
See also: https://betrusted.io
Let’s hope some of that trickles down to consumer hardware.
also this is what happen to prusa, everyone just take the design and outsource the manufacture to somewhere in china which is fine but if everybody doing that, there is no fund to develop next iteration of product (someone has to foot the bill)
and there is not enough sadly, we live in reality after all
This needs money. It is always going to have to pay the costs of being niche, lower performance, and cloneable, so someone has to persuade people to pay for that. Hardware is just fundamentally different. And that's before you get into IP licensing corner cases.
FreeBSD is dumping 32 bit:
https://www.osnews.com/story/138578/freebsd-15-16-to-end-sup...
OpenBSD has this quote:
>...most i386 hardware, only easy and critical security fixes are backported to i386
I tend to think that means 32bit on at least x86 days are numbered.
https://www.openbsd.org/i386.html
I think DragonflyBSD never supported 32bit
For 32bit, I guess NetBSD may eventually be the only game in town.
I think people here are misunderstanding just how "weird" and hacky trying to run an OS like linux on those devices really is.
Not having an MMU puts you more into the territory of DOS than UNIX. There is FreeDOS but I'm pretty sure it's x86-only.
The one thing different to a regular Linux was that a crash of a program was not "drop into debugger" but "device reboots or halts". That part I don't miss at all.
"Originally, fork() didn't do copy on write. Since this made fork() expensive, and fork() was often used to spawn new processes (so often was immediately followed by exec()), an optimized version of fork() appeared: vfork() which shared the memory between parent and child. In those implementations of vfork() the parent would be suspended until the child exec()'ed or _exit()'ed, thus relinquishing the parent's memory. Later, fork() was optimized to do copy on write, making copies of memory pages only when they started differing between parent and child. vfork() later saw renewed interest in ports to !MMU systems (e.g: if you have an ADSL router, it probably runs Linux on a !MMU MIPS CPU), which couldn't do the COW optimization, and moreover could not support fork()'ed processes efficiently.
Other source of inefficiencies in fork() is that it initially duplicates the address space (and page tables) of the parent, which may make running short programs from huge programs relatively slow, or may make the OS deny a fork() thinking there may not be enough memory for it (to workaround this one, you could increase your swap space, or change your OS's memory overcommit settings). As an anecdote, Java 7 uses vfork()/posix_spawn() to avoid these problems.
On the other hand, fork() makes creating several instances of a same process very efficient: e.g: a web server may have several identical processes serving different clients. Other platforms favour threads, because the cost of spawning a different process is much bigger than the cost of duplicating the current process, which can be just a little bigger than that of spawning a new thread. Which is unfortunate, since shared-everything threads are a magnet for errors."
https://stackoverflow.com/questions/8292217/why-fork-works-t...
How do multiple processes actually work, though? Is every executable position-independent? Does the kernel provide the base address(es) in register(s) as part of vfork? Do process heaps have to be constrained so they don't get interleaved?
Executables in a no-MMU environment can also share the same code/read-only segments between many processees, the same way shared libraries can, to save memory and, if run-time relocation is used, to reduce that.
The original design of UNIX ran on machines without an MMU, and they had fork(). Andrew Tanenbaum's classic book which comes with Minix for teaching OS design explains how to fork() without an MMU, as Minix runs on machines without one.
For spawning processes, vfork()+execve() and posix_spawn() are much faster than fork()+execve() from a large process in no-MMU environments though, and almost everything runs fine with vfork() instead of fork(), or threads. So no-MMU Linux provides only vfork(), clone() and pthread_create(), not fork().
[1]: https://maskray.me/blog/2024-02-20-mmu-less-systems-and-fdpi...
[2]: https://popovicu.com/posts/789-kb-linux-without-mmu-riscv/
[3]: https://www.kernel.org/doc/Documentation/nommu-mmap.txt
[4]: https://github.com/kraj/uClibc/blob/ca1c74d67dd115d059a87515...
I spent close to ten years working closely with uClinux (a long time ago). I implemented the shared library support for the m68k. Last I looked, gcc still included my additions for this. This allowed execute in place for both executables and shared libraries -- a real space saver. Another guy on the team managed to squeeze the Linux kernel, a reasonable user space and a full IP/SEC implementation into a unit with 1Mb of flash and 4Mb of RAM which was pretty amazing at the time (we didn't think it was even possible). Better still, from power on to login prompt was well under two seconds.
The original UNIX also did not have the virtual memory as we know it today – page cache, dynamic I/O buffering, memory mapped files (mmap(2)), shared memory etc.
They all require a functioning MMU, without which the functionality would be severely restricted (but not entirely impossible).
The no-MMU version of Linux has all of those features except that memory-mapped files (mmap) are limited. These features are the same as in MMU Linux: page cache, dynamic I/O buffering, shared memory. No-MMU Linux also supports other modern memory-related features, like tmpfs, futexes. I think it even supoprts io_uring.
mmap is supported in no MMU Linux with limitations documented here: https://docs.kernel.org/admin-guide/mm/nommu-mmap.html For example, files in ROM can be mapped read-only.
Access to a page that is not resident in memory results in a trap (an interrupt), which is handled by the MMU – the CPU has no ability to do it by itself. Which is the whole purpose of the MMU and was a major innovation of BSD 4 (a complete VMM overhaul).
But three out of those four features: page cache, dynamic I/O buffering and shared memory between processes, do not require that kind of VMM subsystem, and memory-mapped files don't require it for some kinds of files.
I've worked on the Linux kernel and at one time understood it's mm intimately (I'm mentioned in kernel/futex/core.c).
I've also worked on uClinux (no-MMU) systems, where the Linux mm behaves differently to produce similar behaviours.
I found most userspace C code and well-known CLI software on Linux and nearly all drivers, networking features, storage, high-performance I/O, graphics, futex, etc run just as well on uClinux without source changes, as long as there's enough memory, with some more required because uClinux suffers from a lot more memory fragmentation due to needing physically-contiguous allocations).
This makes no-MMU Linux a lot more useful and versatile than alternative OSes like Zephyr for similar devices, but the limitations and unpredictable memory fragmentation issues make it a lot less useful than Linux with an MMU, even if you have exactly the same RAM and no security or bug concerns.
I'd always recommend an MMU now, even if it's technically possible for most code to run without one.
With the right filesystem (certain kinds of read-only), the code (text segment) can even be mapped directly, and no loading into RAM need occur at all.
These approaches saves memory even on regular MMU platforms.
If you want a hardware architecture you can easily comprehend - and even build your own implementation of! - that's something which RISC-V handles much better than ARM ever did, nommu or otherwise.
It's a 5 gallon pail of compute which is all used up in OS overhead so you can do a cup of work.
If the job were that small that it fits in the remainder, then you could and should have just used 1 cent hardware instead of 1 dollar hardware.
As a reality check: MicroPython can run in 16 KB of RAM; a typical development board has 192 KB. µCLinux requires at least 4 - 8 MB of RAM just to boot up, and recommends 32 MB for a "serious product" [1].
> Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
I would absolutely not count on any of those tools being available and functional in a µCLinux environment.
[1]: https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-...
My point exactly. There's currently a hole between ten-cent MCUs requiring RTOS and 5$+ RPi that can run Linux. Taking out nommu from the kernel would make any 64MB "super-MCU" a non-starter.
I'm not convinced that's true. All of the microcontroller tooling I've seen has been built around RTOS development; I've never seen anything comparable for µCLinux.
That's all worth it to have an application processor that can run your Python/Java app. It's probably worth it to have a consistent operating system across multiple devices.
Would you have many of those benefits if you were using Linux on a micro though? I can't imagine much 3rd party software would work reliably given the tiny amount of RAM. You'd basically just be using it as a task scheduler and wrapper over drivers. You could get most of the benefits by using an RTOS with a memory allocator.
At some point, it might start making sense to level up the OS to (nommu) Linux on these devices. When the applications get complex enough, people find themselves wanting a full blown network stack, full featured storage/file systems that are aligned with non-embedded systems, regular shells, POSIX userland, etc.
All of the architectures I have in mind are 32 bit and "nommu"[1]: Cortex-R52/F, Infineon TriCore, Renesas RH850, NXP Power e200. Then you have RISC-V MCU Cambrian Explosion underway.
I qualify all this with mays and mights: it hasn't happened yet. I'm just careful not to discount the possibly of a <50 mAh RP Pico 3 booting uLinux, running python and serving web pages being a big hit.
[1] They all have various "partition" schemes to isolate banks of RAM for security, reliability, etc., but real MMUs are not offered.
When you have a fleet of embedded devices you want pre-compiled disk images, repeatable builds, read only filesystems, immutable state (apart from small and well controlled partitions), easy atomic updates, relatively small updates (often devices are at the other end of a very slow cell connection) and a very clear picture of what is running on every device in your fleet.
Linux can do all that, but it's not the paradigm that most distros take. Pretty much the entire Linux world is built around mutable systems which update in place. So you're left to manage it yourself. If you want to do it yourself, you end up in the hacky fragile world of Yocto.
Compared to that, using an RTOS or application framework like Zephyr is fairly easy - at the expense of app development time, you just need to worry about getting a fairly small compiled binary onto your device.
I do agree that there's some really powerful parts available which would benefit from the shared drivers and consistent syscalls a standardised operating system offers. But building and maintaining a Linux system for any part isn't a simple undertaking either - and so the complexity of that needs to be considered in total development time.
Linux is too unorthogonal for them.
What's missing? What would it take to make a plain RTOS that's as easy to develop on/for/with as Linux?
Simple and POSIX would be a BSD like NetBSD or OpenBSD.
This is why I gravitated to Plan 9. Overall a better design for a networked world and can be understood by a single developer. People can and have maintained their own forks. Its very simple, small and cross platform was baked in from day one. 9P makes everything into a IO socket organized as a tree of names objects. Thankfully it's not POSIX which IMO is not worth dragging along for decades. You can port Unix things with libraries. It also abandons the typewriter terminal and instead uses graphics. A fork, 9front, is not abandoning 32 bit any time soon AFIK. I netboot an older Industrial computer that is a 400MHz Geode (32 bit x86) with 128 MB RAM and it runs 9front just fine.
Its not perfect and lacks features but that stands to reason for any niche OS without a large community. Figure out what is missing for you and work on fixing it - patches welcome.
Think about it like CreateProcess() on Windows. Windows is another operating system which doesn't support fork(). (Cygwin did unholy things to make it work anyway, IIRC.)
And given the target market (even the biggest Zephyr targets have addressable RAM in the megabytes, not gigabytes), there's no self-hosting notion. You build on a big system and flash to your target, always. So there's no single filesystem image (though it supports a somewhat limited filesystem layer for the external storage these devices tend to see) containing "programs" to run (even though there's a ELF-like runtime linker to use if you want it).
If you want it to look like Linux: no, that's not what it's for. If you want to target a Cortex-M or ESP32 or whatever on which Linux won't run, it gives you the tools you expect to see.
Two things standout to me: (1) It was written in 2006. RISC V was not released until 2010 (so says Google). I guess it was ported from x86? (2) Russ Cox is one of the contacts listed on MIT homepage. That guy's digital footprints are enormous.
That isn't necessarily the case. You can have memory protection without a MMU - for instance, most ARM Cortex-M parts have a MPU which can be used to restrict a thread's access to memory ranges or to hardware. What it doesn't get you is memory remapping, which is necessary for features like virtual memory.
Most likely I won't be around this realm when that takes shape, but I predict the GNU/Linux explosion replacing UNIX was only a phase in computing history, eventually when everyone responsible for its success fades away, other agendas will take over.
It is no accident that the alternatives I mention, are all based on copyleft licenses.
This is a young mans' game, and I am very much not.
The industry has a lot of experience doing so.
In parallel, the old hardware is still supported, just not by the newest Linux Kernel. Which should be fine anyway because either you are not changing anything on that system anyway or you have your whole tool stack available to just patch it yourself.
But the benefit would be a easier and smaller linux kernel which would probably benefit a lot more people.
Also if our society is no longer able to produce chips in a commercial way and we loose all the experience people have, we are probably having a lot bigger issues as a whole society.
But I don't want to deny that it would be nice to have the simplest way of making a small microcontroller yourself (doesn't has to be fast or super easy just doable) would be very cool and could already solve a lot of issues if we would need to restart society from wikipedia.
Note ELKS is not Linux.
There's also Fuzix.
Linux remains open source, extendable, and someone would most likely maintain these ripped out modules. Just not at the expense of the singular maintainer of the subsystem inside the kernel.
Linux's master branch is actually called master. Not that it really matters either way (hopefully most people have realised by now that it was never really 'non-inclusive' to normal people) but pays to be accurate.
In this case, out of dozens of ways the word is used (others being like ‘masters degree’ or ones that pretty closely match Git’s usage like ‘master recording’ in music), one possible one is ‘slavemaster’, so some started to assert we have to protect people from possibly making the association.
The relation between a human and a computer is very much that of a master and a slave. I provide the resources, you do what I say, including self-destruction.
> Not that it really matters either way
But you still decided to make it your personal battle to make a comment remind people that the evil inclusive people did a no no by forcing you to rename your branches from master to main, yes.
>pays to be accurate.
No, it doesn't. Source: you knew exactly what I was talking about when I said main. You also would have known what I was talking about had I said trunk, master, develop or latest.
It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC.
Main-core computing is vastly more homogenous than when I was born almost 50 years ago. I guess that's a natural progression for technology.
I wish the same applied to written numbers in LTR scripts. Arithmetic operations would be a lot easier to do that way on paper or even mentally. I also wish that the world would settle on a sane date-time format like the ISO 8601 or RFC 3339 (both of which would reverse if my first wish is also granted).
> It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC.
I never really understood those non-8-bit bytes, especially the 7 bit byte. If you consider the multiplexer and demux/decoder circuits that are used heavily in CPUs, FPGAs and custom digital circuits, the only number that really makes sense is 8. It's what you get for a 3 bit selector code. The other nearby values being 4 and 16. Why did they go for 7 bits instead of 8? I assume that it was a design choice made long before I was even born. Does anybody know the rationale?
IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.
There's mainly one country which messes things up...
If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?
On the other hand, if it's data for computer consumption then just skip the complicated serialisation completely and dump the Unix timestamp as a decimal. Any modern data format would include the ability to label that as a timestamp data type. If you really want to be able to "read" the data file then just include another column with a human-formatted timestamp, but I can't imagine why in 2025 I would be manually reading through a data file like some ancient mathematician using a printed table of logarithms.
If you're naming a document for human consumption, having the files sorted by date easily without relying on modification date (which is changed by fixing a typo/etc...) is pretty neat
Its a serialization and machine communication format. And that makes me sad. Because YYYY-MM-DD is a great format, without a good name.
[1] https://www.pvv.org/~nsaa/8601v2000.pdf
> NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
When your RAM is vacuum tubes or magnetic core memory, you don't want 25% of it to go unused, just to round your word size up a power of two.
wasnt this more to do with cost? they could do arbitrary precision code even back then. its not like they were only calculating numbers less than 65537, ignoring anything larger
For the representation of text of an alphabetic language, you need to hit 6 bits if your script doesn't have case and 7 bits if it does have case. ASCII ended up encoding English into 7 bits and EBCDIC chose 8 bits (as it's based on a binary-coded decimal scheme which packs a decimal digit into 4 bits). Early machines did choose to use the unused high bit of an ASCII character stored in 8 bits as a parity bit, but most machines have instead opted to extend the character repertoire in a variety of incompatible ways, which eventually led to Unicode.
I wouldn’t be surprised if other machines had something like this in hardware.
Only if you assume a 1:1 mapping. But e.g. the original Baudot code was 5-bit, with codes reserved to switch between letters and "everything else". When ASCII was designed, some people wanted to keep the same arrangement.
[1] Yes, I remember you could bit-bang a UART in software, but still the parity bit didn't escape the serial decoding routine.
But why? The brilliance of 8601/3339 is that string sorting is also correct datetime sorting.
To get the little-endian ordering. The place values of digits increase from left to right - in the same direction as how we write literature (assuming LTR scripts), allowing us to do arithmetic operations (addition, multiplication, etc) in the same direction.
> The brilliance of 8601/3339 is that string sorting is also correct datetime sorting.
I hadn't thought about that. But it does reveal something interesting. In literature, we assign the highest significance to the left-most (first) letter - in the direction opposite to how we write. This needs a bit more contemplation.
Yes, we do that with everything, which is why little-endian numbers would be really inconsistent for humans.
Doing numbers little-endian does make more sense. It's weird that we switch to RTL when doing arithmetic. Amusingly the Wikipedia page for Hindu-Arabic numeral system claims that their RTL scripts switch to LTR for numbers. Nope... the inventors of our numeral system used little-endian and we forgot to reverse it for our LTR scripts...
Edit: I had to pull out Knuth here (vol. 2). So apparently the original Hindu scripts were LTR, like Latin, and Arabic is RTL. According to Knuth the earliest known Hindu manuscripts have the numbers "backwards", meaning most significant digit at the right, but soon switched to most significant at the left. So I read that as starting in little-endian but switching to big-endian.
These were later translated to Arabic (RTL), but the order of writing numbers remained the same, so became little-endian ("backwards").
Later still the numerals were introduced into Latin but, again, the order remained the same, so becoming big-endian again.
And as for numbers, perhaps it isn't too late to set it right once and for all. The French did that with the SI system after all.
> So apparently the original Hindu scripts were LTR
I can confirm. All Indian scripts are LTR (Though there are quite a few of them. I'm not aware of any exceptions). All of them seem to have evolved from an ancient and now extinct script named Brahmi. That one was LTR. It's unlikely to have switched direction any time during subsequent evolution into modern scripts.
YYYY-MM-DD to me always feels like a timestamp, while when I want to write a date, I think of a name, (for me DD. MM. YYYY).
For better or worse, PowerPC is still quite entrenched in the industrial embedded space.
[1] Ok I admit, not trivially when it comes to unpaired surrogates, BOMs, endian detection, and probably a dozen other edge and corner cases I don't even know about. But you can offload the work to pretty well-understood and trouble-free library calls.
Most Unix syscalls use C-style strings, which are a string of 8-bit bytes terminated with a zero byte. With many (most?) character encodings you can continue to present string data to syscalls in the same way, since they often also reserved a byte value of zero for the same purpose. Even some multi-byte encodings would work if they chose to avoid using 0-value bytes for this reason.
UTF-16LE/BE (and UTF-32 for that matter) chose not to allow for this, and the result is that if you want UTF-16 support in your existing C-string-based syscalls you need to make a second copy of every syscall which supports strings in your UTF-16 type of choice.
That's completely wrong. If a syscall (or a function) expects text in encoding A, you should not be sending it in encoding B because it would be interpreted incorrectly, or even worse, this would become a vulnerability.
For every function, encoding must be specified as are specified the types of arguments, constraints and ownership rules. Sadly many open source libraries do not do it. How are you supposed to call a function when you don't know the expected encoding?
Also, it is better to send a pointer and a length of the string rather than potentially infinitely search for a zero byte.
> and the result is that if you want UTF-16 support in your existing C-string-based syscalls
There is no need to support multiple encodings, it only makes things complicated. The simplest solution would be to use UTF-8 for all kernel facilities as a standard.
For example, it would be better if open() syscall required valid UTF-8 string for a file name. This would leave no possibility for displaying file names as question marks.
Unfortunately some text encodings (UTF-16 among them) use nuls for codepoints other than U+00. In fact UTF-16 will use nuls for every character before U+100, in other words all of ASCII and Latin-1. Therefore you can't just support _all_ text encodings for filenames on these OSes, unless the OS provides a second syscall for it (this is what Windows did since they wanted to use UTF-16LE across the board).
I've only mentioned syscalls in this, in truth it extends all through the C stdlib which everything ends up using in some way as well.
It is good for an implementation to enforce this at some level, sure. MacOS has proved features like case insensitivity and unicode normalization can be integrated with Unix filename APIs.
And you should be using one specified encoding for file names if you want them to be displayed correctly in all applications. It would be inconvenient if different applications stored file names in different encodings.
For the same reason, encoding should be specified in libraries documentation for all functions accepting or returning strings.
So it's far more pervasive than people think, and will likely be in the picture for decades to come.
Of course they chose to integrate JavaScript so that's less likely now.
UTF-16 is annoying, but it's far from the biggest design failure in Unicode.
Then there is also the issue that technically there is no such thing as UTF-16, instead you need to distinguish UTF-16LE and UTF-16BE. Even though approximately no one uses the latter we still can't ignore it and have to prepend documents and strings with byte order markers (another wasted pair of code points for the sake of an encoding issue) which mean you can't even trivially concatenate them anymore.
Meanwhile UTF-8 is backwards compatible with ASCII, byte order independent, has tons of useful properties and didn't require any Unicode code point assignments to achieve that.
The only reason we have UTF-16 is because early adopters of Unicode bet on UCS-2 and were too cheap to correct their mistake properly when it became clear that two bytes wasn't going to be enough. It's a dirty hack to cover up a mistake that should have never existed.
That's a strange way to characterize years of backwards compatibility to deal with
https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=10...
I disagree you could just "easily" shove it into the "A" version of functions. Functions that accept UTF-8 could accept ASCII, but you can't just change the semantics of existing functions that emit text because it would blow up backwards compatibility. In a sense it is covariant but not contravariant.
And now, after you've gone through all of this effort: what was the actual payoff? And at what cost if maintaining compatibility with the other representations?
UTF-32 is the worst of all worlds. UTF-16 has the teeny tiny advantage that pure Chinese text takes a bit less space in UTF-16 than UTF-8 (typically irrelevant because that advantage is outweighed by the fact that the markup surrounding the text takes more space). UTF-8 is the best option for pretty much everything.
As a consequence, never use UTF-32, only use UTF-16 where necessary due to backwards compatibility, always use UTF-8 where possible.
There's also the problem that grapheme cluster boundaries change over time. Unicode has become a true mess.
Not really. Unicode is still fundamentally based off of the codepoints, which go from 0 to 2^16 + 2^20, and all of the algorithms of Unicode properties operate on these codepoints. It's just that Unicode has left open a gap of codepoints so that the upper 2^20 codepoints can be encoded in UTF-16 without risk of confusion of other UCS-2 text.
The expansion of Unicode beyond the BMP was designed to facilitate an upgrade compatibility path from UCS-2 systems, but it is extremely incorrect to somehow equate Unicode with UTF-16.
Also ISO 8601 (YYYY-MM-DD) should be the default date format.
I have a relatively large array of uint16_t with highly repetitive (low entropy) data. I want to serialize that to disk, without wasting a lot of space. I run compress2 from zlib on the data when serializinsg it, and decompress it when deserializing. However, these files make sense to use between machines, so I have defined the file format to use compressed little endian 16-bit unsigned ints. Therefore, if you ever want to run this code on a big-endian machine, you need to add some code to first flip the bytes around before compressing, then flipping them back after decompressing.
You're right that when your code is iterating through data byte for byte, you can write it in an endian-agnostic way and let the optimizer take care of recognizing that your shifts and ORs can be replaced with a memcpy on little-endian systems. But it's not always that simple.
Hey, you! You're supposed to be dead!
https://wiki.netbsd.org/ports/evbarm/
May be someone can develop such thunking for legacy Linux userland.
The only thing I can think of is games, and the Windows binary most likely works better under Wine anyways.
There are many embedded systems like CNC controllers, advertisement displays, etc... that run those old applications, but I seriously doubt anyone would be willing to update the software in those things.
that said, i sometimes think about a clean-room reimplementation of e.g. the unity3d runtime -- there are so many games that don't even use native code logic (which still could be supported with binary translation via e.g. unicorn) and are really just mono bytecode but still can't be run on platforms for which their authors didn't think to build them (or which were not supported by the unity runtime at the time of the game's release).
Yeah, that's a reasonable workaround, as long as it doesn't hit that OpenGL problem above (now it mostly affects DX7 era games, since they don't have Vulkan translation path). Hopefully it can be fixed.
Win64S?
I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore.
Now Linux will be in the same lane as osx and windows running after the last shiny new things, and being like: if you want it, buy a new machine that will support it.
If you install 6.12 today (via e.g. Debian 13) then you'll be good until at least 2035. So removing it now de-facto means it will be removed in >10 years.
And as the article explains, this mostly concerns pretty old systems. Are people running the latest kernel on those? Most of the time probably not. This is really not "running after the last shiny thing". That's just nonsensical extreme black/white thinking.
From a user's perspective, they just keep working.
Lots of distros already dropped 32 bit kernel support and it didn't cause much fuss.
It's not even like we're breaking them. This is just the maintainers of the Linux kernel choosing to not spend their time maintaining compatibility with the old architectures.
A computer you buy today will be much more viable in 20+ years than a 20+ year old computer is right now. We were still in the extreme part of speed and density growth back than, and it will lessen every decade.
Houses are obviously very different to computers. Do you also demand 20 year lifetimes for your socks?
Maybe it is not that the architecture was not compatible as much as it was restricted or limited by Intel and co for these cpus
For mainstream laptops/desktops, the 32 bit era ended around 2006 (2003, if you were smart and using Athlon 64s instead of rancid Pentium 4).
Netbooks and other really weak devices held out a few years longer, but by 2010, almost everything new on the market, and a good chunk of the second-hand market, was already 64 bits.
Case in point, I'm writing on a x86_64 laptop that was a free give away to me about a year ago with a CPU release year that is 2012.
I have personally given away a x86_64 desktop unit years ago that was even older, might have had DDR1 memory.
Circa 2013 my old company was gifted a x86_64 motherboard with DDR2 memory that ended up serving as our in-office server for many years. We maxed the RAM (8GB) and at some point bought a CPU upgrade on ebay that gave us hardware virtualization extensions.
Same for WASM -- 32-bit pointers, 64-bit integers.
Both of these platforms have a 32-bit address space -- both for physical addresses and virtual addresses.
Ripping out support for 32-bit pointers seems like a bad idea.
RAM limitations were one reason to use arm64_32, but a bigger reason is that the first watches were only ARMv7 (32-bit) so by sticking with 32-bit pointers, Apple was able to statically recompile all the 3rd party (ARMv7) apps from LLVM bitcode to arm64_32.
https://www.macrumors.com/2025/06/16/watchos-26-moves-apple-...
It follows the latest LTS which I think is reasonable especially since phone vendors wants to have support for the device for several years.
The costs of distros and the kernel steadily dropping older x86 support over the last few years never causes an outcry but it's an erosion of what made Linux great. Especially for non-English speaking people in less developed countries.
Open-source maintenance is not a obligation, but it's sad there is not more people pushing to maintain support. Especially for the "universal operating system" Debian which was previously a gold standard in architecture support.
I maintain a relatively popular live Linux distro based on Ubuntu and due to user demand will look into a NetBSD variant to continue support (as suggested in this thread), potentially to support legacy 586 and 686 too.
Though a Debian 13 "Trixie" variant with a custom compiled 686 kernel will be much easier than switching to NetBSD, it appears like NetBSD has more commitment to longer-term arch support.
It would be wonderful to develop systems (eg emulation) to make it practical to support architectures as close to indefinitely as possible.
It does feel like a big end of an era moment for Linux and distros here, with the project following the kind of decision making of big tech companies rather than the ideals of computer enthusiasts.
Right now these deprecation decisions will directly make me spend time working at layers of abstraction I wasn't intending to in order to mitigate the upstream deprecations of the kernels and distros. The reason I have used the kernel and distros like Debian has been to offload that work to the specialist maintainers of the open-source community.
E.g. there's some stuff like erratum workarounds for old x86 CPUs that would be nice to drop, but they are part of a big framework for handling x86 diversity. Dropping individual workarounds doesn't let you drop the framework.
Exceptions are gonna be cases where dropping the support removed something significant from the lowest common denominator. Big stuff like word size, memory ordering (I assume dropping Alpha would be quite handy), virtual address space limitations.
You can be so flexible that it turns everything into a giant slog. I doubt 32 bit support is anywhere near that horrid; commenting on the idea more than this specific case.
Part of the problem with these discussion is that often when people say "64-bit" vs "32-bit" they are also considering all the new useful instructions that were added to the new instruction set generation. But a true "apples-to-apples" comparison between "32-bit" and "64-bit" should be using almost identical whose only difference is the datapath and pointer size.
I feel that the programs and games I run shouldn't really need more than 4GB memory anyway, and the occasion instance that the extra precision of 64-bit math is useful could be handled by emulating the 64-bit math with the compiler adding a couple extra 32-bit instructions.
When you factor in memory fragmentation, you really only had a solid 0.75-1.5GB of space that could be kept continuously in use. That was starting to become a problem even when 32-bit was the only practical option. A lot of games saw a benefit to just having the larger address space, such that they ran better in 64-bit with only 4GB of RAM despite the fatter 64-bit pointers.
And 3-1 wasn't really experimental. It was essentially always that way under Linux, and had been supported under Windows since the late 90s.
I think it would be possible for e.g. microkernels to greatly reduce the size of the reservation (though not to eliminate it entirely). However, I can't imagine how you would handle the privilege escalation issue without having at least some system code in the application's virtual address space that's not modifiable by the application.
Such a design may require at least one processor dedicated to running the kernel at all times, so it might not work on a single processor architecture. However, single processor architectures might be supportable by having the "kernel process" go to sleep by arming a timer and the timer interrupt is the only one that's specially mapped so it can modify the page table to resume the kernel (for handling all the ring buffers + scheduling). As you note, there's some reserved address space but it's a trivial amount just to be able to resume running the kernel. I don't think it has anything to do with monolithic vs microkernels.
If you just want constant-time operations, you just need dedicated instructions. Maybe they run on dedicated cores, but that's an implementation detail. I think this is a good idea, and it feels like we're heading this way already, more or less.
If you want to address all of the vulnerabilities that have arisen, you need full isolation. As mentioned in a sibling comment, you can't share any memory or caches etc. Each "security core" would have to be fully isolated from every other core, including every other security core. And you also need to segregate out "sensitive" code and data from non-sensitive code and data. When all is said and done, I don't see how we're talking about anything less than scrapping all existing ISAs, and perhaps even von Neumann architecture itself. I'm sure there are some middle-ground solutions between where we are today and this extreme, but I think they're going to look more like TPM/Secure Enclave than special cores, and they're only going to partially address the vulnerabilities.
https://wiki.debian.org/X32Port
Really the ALU width is an internal implementation detail/optimisation, you can tune it to the size you want at the cost of more cycles to actually complete the full width.
Lots of machines are capable of running with 32-bit pointers and 64-bit integers ("Knuth mode" aka "ILP32"). You get a huge improvement in memory density as long as no single process needs more than 4GB of core.
But really that's a software/OS level thing, and though the benefits have definitely been shown, the seem small enough to not be worth the upheaval.
Though possibly related, larger pages have been shown to have significant speedups without changing the ABI (as much, at least mmap() and similar will have slightly different specifics). IMHO the only possible "benefit" to 4kb page sizes is to (ab)use it to trap things like array overruns - though using that is a poor substitute for /real/ bounds checking - a lot can go wrong within 4kb, after all.
I saw this last in SmartOS.
I couldn't tell if your comment was a joke, but it is worth mentioning the 8-bit microcontrollers like TinyAVR still fill a niche where every joule and cent counts.
Compared to ARM-based systems? Nope.
I'm pretty shocked to see comments like "the RAM for a 32-bit system costs more than the CPU itself", but open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running.
I understand that maintainers don’t want to drag around unmaintained code forever, and that testing on rare hardware is difficult. But if the code already exists and is working, is it really that costly to just not break it? The kernel's history is full of examples where obscure architectures and configs were kept alive for decades with minimal intervention. Removing them feels like a philosophical shift, especially when modern hardware is more locked down and has a variety of black box systems running behind it like Intel ME and AMD PSP.
Not really. The discussion is about cost, benefits and available resources. Projects are not immune because they are open source or free software. Actual people still need to do the work.
> Open source has always been about making hardware outlive commercial interest and let it run long after the hardware vendor abandons it.
Again, not really. Open source has always been all about freely modifying and distributing software. This leaves some freedom for anyone to keep supporting their pet hardware, but that’s a consequence. In this case, I don’t think it would be a real problem if anyone would step up and commit the ressources necessary to keep supporting older hardware. This freedom was not taken away because a project’s developers decided that something was not worth their time anymore.
It depends on the feature, but in many cases the answer is in fact 'yes.' There's a reason why Alpha support (defunct for decades) still goes on but Itanium support (defunct for years) has thoroughly been ripped out of systems.
Well, there really wasn't much support for atomic instructions in x86 before the introduction of compare-exchange in the 486. Any time you wanted guaranteed atomicity on a 386 you had to disable interrupts, which among other things means that if you lock up during a critical section your entire system hangs. Another implication is that nearly all of our lockless data structure constructs depend on compare-exchange instructions.
It vastly simplified some very tricky sections of the kernel to remove support for systems that don't have hardware atomic instructions, so it ended up being done.
There's not a compelling reason to run a bleeding edge kernel on a 2004 computer, and definitely not one worth justifying making the kernel devs support that setup.
But in any case, I’m sure Red Hat etc would be happy to sell backports of relevant fixes.
It’s not that I’m unsympathetic to people with older systems. I get it. I’ve got old hardware floating around that I’ve successfully kept my wife from ecycling. It’s that I’m also sympathetic to the kernel devs who only have so many hours, and don’t want to use them supporting ancient systems that aren’t still widely used.
For legacy hardware like this it's usually not anywhere close to as important as it is for modern systems.
These systems are not being used to browse the modern web, they're too slow.
They're not being used to host production multiuser environments beyond a few retrocomputing homelabbers' toy systems, where the worst case scenario is a restore from backup and banning a user or two rather than data loss/breach and/or legal action.
The ones still in actual active use are almost all appliance systems that mostly haven't seen a kernel update in years or ever because they are usually exist to go with some piece of hardware that never got an in-tree driver and thus can't work with anything much newer than what it shipped with and/or some software that depends on ancient libraries no distro ships anymore. These systems don't need to (and shouldn't) be exposed to untrusted networks, users, or content, they can (and already should) be locked down by a skilled admin to only communicate with the minimum number of systems needed for whatever purpose they serve. If the admin isn't sufficiently skilled to confidently handle that, the system and admin should both be replaced.
---
I have an old IBM PS/2 that's my family's first computer, which still has its original Windows 3.1 install on it. I imaged the original hard drive and moved it to a CF card, but that also means I can screw around with it and not worry about breaking anything because I can just restore the last known good image. I don't connect it to the internet often but if on one of those rare times I happened to somehow stumble upon someone who had been saving a drive-by exploit for IE 3.0 or a RCE against Trumpet Winsock that then infected my system I'd just do the same. Anything this old is small enough to be imaged easily.
Ehhh, it's about users having the ability to run whatever they like. Which they do.
If a group of users of 32 bit hardware care to volunteer to support the latest kernel features, then there's no problem.
If no one does, then why should a volunteer care enough to do it for them? It's not like the old kernel versions will stop working. Forcing volunteers to work on something they don't want to do is just a bad way to manage volunteers.
It's not just the case that you need people to support 32bit/nommu; you also have to account for the impact on other kernel devs working on features that are made harder.
This is called out in the article around keeping highmem support.
The other dynamic here is that the direction in Linux does come from the top. When you have maintainers like Arnd Bergmann saying they would "like" to remove support for hardware (like the ARM boards), that sets the tone, and other contributors will naturally follow that lead. If leadership encouraged a philosophy closer to "never break existing hardware" the same way we’ve had "never break userspace" for decades, we probably wouldn’t even be debating removing 32 bit.
I’m not saying kernel devs need to carry the weight alone, but it would be nice if the community’s baseline stance was towards preservation rather than obsolescence. :(
> The kernel is still adding support for some 32-bit boards, he said, but at least ten new 64-bit boards gain support for each 32-bit one.
And
> To summarize, he said, the kernel will have to retain support for armv7 systems for at least another ten years. Boards are still being produced with these CPUs, so even ten years may be optimistic for removal. Everything else, he said, will probably fade away sooner than that.
So, no, he does not think that at all.
Wild, like some kind of virtual cache. Reminds me a bit of the old Macintosh 68k accelerators; sometimes they included their own (faster) memory and you could use the existing sticks as a RAM disk.
The "steam client" is still a 32 bits ELF executable, which statically loads openGL and x11 libs... (namely not even a wayland->x11 fallback or a opengl->CPU rendering).
We would be all better with a nogfx static PIE executable, even a nogfx dynamic PIE executable if they want to explore the ELF setup of a distro.
Ohhh yes!
So, a couple of weeks ago I came across a discussion where some distro (I don't remember which one) contemplated removing 32-bit user space support, suggesting to users to simply run a VM running a 32 bit Linux instead. It was a stupid suggestion then, and this statement is a nice authorative answer from the kernel side, where such suggestions can be shoved to.
"Linking against 32-bit multilib packages has been removed. The *.i686 packages remain supported for the life cycle of Red Hat Enterprise Linux 9."
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.
I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.
[1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds
I'm sure it'll cause someone some issues, but it'll be very niche by 2038. Most of the sorts of systems that it could cause problems for aren't being used to plan things years in advance, some probably don't even do anything with the date. So it's a niche within a niche (unupdatable systems used for future planning) that's likely to have problems soon, and overall probably no longer a big deal.
TL;DR: It's solved upstream, only an issue for some systems that don't get updates.
Like on Armv7-M it's said "Nobody is building anything with this kind of hardware now" - this is just wrong to the point of ridiculousness. Thousands of new products will be designed using these microcontrollers and still billions of units will be produced with them in them - now, true that almost none of those will run Linux on those MCUs but it's crazy to say "nobody" is building things with them. Many of course are moving to Armv8-M microcontrollers but those are 32 bit too!
On the Linux side, there are things like the AMD/Xillinx Zynq-7000 series that will be supported for many years to come.
It's not the worst idea in the world to deprecate support for 32-bit x86 but it is not time to remove it for ARM for many years yet.
2. That sentence wasn't about 32-bit, it was about devices without MMUs.