If we’re talking about oxidized iron… probably nobody. If we’re talking about Rust the programming language, well, that might be a different story. Google agrees, and is working on bringing the language into Android. That’s not enough for [Paul Sanja], who has the first Redox OS smartphone.
Redox OS is a Unix-like operating system written entirely in Rust, and somehow we haven’t covered it until now. Unlike Asterinas, a project to recreate the Linux kernel in Rust, Redox has few pretensions of being anything but its own thing, and that’s great! On desktop, Redox has a working windowing system and many utilities, including a basic browser in the form of NetSurf.
It’s claims to be source-compatible with Linux and BSD programs, and partially POSIX compliant. A certain someone around here might want to try it as a daily driver. The header image is a desktop screenshot, because there’s more to see there and it fits our aspect ratio.
On smartphones, it… boots. Some smartphones, anyway. It’s actually a big first step. That booting is possible is actually thanks to the great work put in by the Postmarket OS team to get Uboot working on select android devices. That uboot loader doesn’t need to load the Linux-based Postmarket OS. It can be used for anything compatible. Like, say, Redox OS, as [Paul] shows us.
Of course, Redox OS has no drivers for the touchscreen or anything else, so at the moment that rusty smartphone can only boot to a login screen. But thanks to Rust, you can rest assured that login screen hasn’t got any memory leaks! Jokes aside, this is a great start and we’re hoping to see more.
Redox is a promising project on mobile or desktop, and its development seems a much better use of time and effort than fighting over Rust in the Linux kernel.
I wish people would sit back and reconsider whether POSIX API from 1970s designed to work as embedded system in telephone exchanges is really fit for computing problems of 2025 – this includes ergonomics. People who are not interested in computers and don’t want to learn should not be forced to think in patterns introduced by academics of 1970s (for example pipes, sockets or “root” filesystem).
What’s wrong with representing system disk as
C:\instead of/dev/balls/cum/jp2/gmd-2137-06247u6980248x/XD/1Why C:\? That’s a hold over from MSDOS from 1981.
Why C? Because A and B were already occupied by diskette drives. C was the first free letter after the standard 2 diskette drives. How many phones do you know that sport a 5 and 1/4 inch diskette drive? None? Then why maintain compatibility with something that no one else understands – just like pipes, sockets and a root filesystem. C: is nothing other than the root file system as originally envisioned on a PC running MSDOS.
Someone out there is thinking “challenge accepted.”
I had everything to do this on hand, so why not.
https://www.youtube.com/watch?v=VahuI9jt1L8
That’s pretty darned cool!
I’ve submitted your hack to Hackaday as a hack. Maybe it’ll show up on the front page one day.
I’m totally writing this one up. See you on the front page (again!)
Replying to:
Tyler August’s submission was posted on main page as How Many Phones Sport A 5 And 1/4 Diskette Drive? This One on Sept. 27.
My thoughts exactly!
My first real XT-compatible system had 4 floppy drives, and thus my hard drive was E:\
format C:is an easily understood meme relating to re-installing Windows which takes a lot of time – for example you need to first make an image with nLite, then burn it to DVD-R, then install all drivers and software, copy all files etc. If you just said: “I’m going toformat E:this evening” people would think you’re just formatting a pendrive and that’s no excuse for not coming over for a beer and grilled sausage.Man I have heard a lot of complaints about UNIX over the years but I think this has to be the first to complain that /home/bob is more complex then C:/Users/Bob/. But hey on the bright side on windows you could also write c:/USERS/bob and get to the same place because Windows file system is not case sensitive and that has never caused an issue for anyone ever.
It’s well known that Microsoft is a lot more tolerant to shouting that anyone else. Even Ballmer can teach you a lesson about this.
Pretty sure it causes less issues than a FS where every object-name with X letters[1] in it can have X² other objects in the same place with the “same” name…
[1] all capitalizeable alphabetic characters.
Actually… 2^X, so even worse.
This seems like a nonsense argument when it’s MUCH easier to distinguish between
Readme.mdandreadme.mdthan it is to tellread-me.mdread–me.mdandread—me.mdapart. But nobody’s dragging Unicode support in file names.More to the point, I’ve never seen a troll (sorry, Maria, but if it quacks like a duck…) be so lazy as to pretend that the equivalent to
C:\on a Linux machine is some convoluted device path, and not just/. I mean, yourC:\drive has a MUCH more complicated device path on Windows, too, and I have no idea what it is since it doesn’t matter. Nor does the device path to my Linux disks. (I just checked, for fun. On the one Windows machine I have it’sSCSI\DISK&VEN_KINGSTON&PROD_SA400S37240G\4&197CBE27&0&000000. Or you could call itmulti(0)disk(0)risk(0)partition(3). OR\Device\Harddisk0\Partition3.)*rdisk, notrisk.I find the POSIX trivial since you can store the base file paths as strings and append new file paths as strings and therefore only have to type the whole thing once. As for the the people allergic to learning but still some reason want to do a technical project like this they can copy paste someone else’s work from a guide or sometimes even run a script some other person has made to make it easy.
Catering to the detail adverse and breaking backwards compatibility doesn’t make sense when the ergonomic aspect is made moot by any programming language being able to store variables of which includes all POSIX compliant languages. Especially so when it is easily automatable.
Think for one second about the concept available in 1970. Are they fundamentally different from the one we have now ? Would it make sense not to have any file in an operating system? Not to have programs ? Not to have user input devices ?
Then how would you combine an OS to handle user input and give it to one or more program? How do you manage to process the output of the program and send it to an output device (screen, speaker, whatever) ?
Sure, at kernel level, you can do whatever you want. I’m dreaming of a micro kernel that’s not having any syscall and using only a io_uring like interface for communication with the user programs (it’s definitively possible right now, if we were to throw the 50 last year of cruft). But at a user level, things are unfortunately hold in ice. You’ll never reprogram your users not to use their finger and their eyes (maybe even their ears). So the screen, speaker, and a tactile interface is required whatsoever.
Then, if you build up on this, you’ll realize that the abstraction in POSIX to have everything accessible via a single object (called a “file”, why???) is the root of all you can do. Even Windows does this with its HANDLE. It’s the natural and ultimate abstraction, you can’t ignore it, you can’t escape it either.
For those people that are technically challenged that way, there is a nice POSIX construct called “symbolic links”, so you could literally make your own
C:/like this “ln /dev/balls/cum/jp2/gmd-2137-06247u6980248x/XD/1 /C:” (to use your example path).It would probably be more relevant to have it in their home directory than in the root of the filesystem, unless the computer is truly personal.
indeed they are symbolic links in Windows as well; e.g. on my system:
C: -> \Device\HarddiskVolume5
Symbolic links in the filesystem in Windows have been around for many years, but admittedly they are awkward to use because you need a privilege to create them, and moreover most programs are not link aware and may behave abnormally. But many times not!
NTFS supports hard-links (files on the same “partition”) and junctions (folders anywhere) since Windows NT 4 too – without requiring elevated rights.
But one needs extra helper programs to properly use.
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html
And what would you use instead of Pipes? Fundamentally its a core requirement to a function system IMO. And thanks to all the GUI stuff created to abstract the functions actually being done one you a lazy user will never have to actually interact yourself. But the power user…
Same with the filesystems your file browser will almost certainly have a quick links automatically populated to external drives and common folders you’d need, so whether its mounted to “Z:\Stuff\Oh God too much junk” or /home/Documents/Oh\ God\ too\ much\ junk/ or /run/media/user/UUID/ or /dev/sdb1 is entirely irrelevant to you in use.
POSIX simply works, and nothing functionally better has actually been created, or far as I can tell ever really theorised – any alternative seems to be made entirely because its a fun computer science learning project, not because they believe there is actually something to improve…
I do sometimes wish that pipes could transmit complex structured data, complete with schema. It was a feature that I became fond of back when I wrote a lot of Powershell, and now whenever I have to work with stringly-typed data I feel like a caveman.
You could use Python. It’s Open Software unlike M$ PS.
what are you talking about?
https://github.com/PowerShell/PowerShell
by some arguments it’s even more open than python as it uses a standard MIT license rather than the Python license
In code, you’re probably looking for Google’s Protocol Buffers. It doesn’t help with a shell pipeline, but for IPC and data-sharing it’s pretty great. Better than hand-rolling your own serialization protocol, anyway. And it’s highly cross-everything.
POSIX is a late 1980’s concept.
Disk operating systems made a lot of sense for users who had physical access to machines and needed to keep careful track of which physical disk their files were on. Many users (not all, of course) only have one hard drive and rarely use physical disks these days, so I find the legacy UNIX way of dealing with drives less annoying as time goes on. YMMV.
There was a Linux distribution years ago that tried to do what you want– create a DOS-like filesystem that’s more user-readable. IIRC it was Gobo Linux, and still seems to be around.
i agree with the other replies of course
but i am interested in the constant “why don’t people reconsider?” it’s evergreen in every field. but everything is constantly being reconsidered. you might ask, why do we have a 200+ year old form of government (referring to the US constitution)? and people are always getting the impression that it is somehow static. that there is a natural way things are. but key organizational principles like how the 3 branches relate to eachother are constantly being reinvented. every line is always moving.
so with a technical choice like this one, having to do with our most abstract castles in the sky, it is reconsidered even more vigorously. the cost of reinventing an idea is “just” moving bits and bytes around! never has it been easier for an industry to reconfigure itself overnight. and amidst all this reinvention and reconsideration, the things which remain the same are truly “time-tested.”
people don’t necessarily make good decisions but there’s always a real reason for something to be maintained into the next generation. even things we may dismiss as superstition, like religion, serve some sort of function. humanity can’t stand still, and the things we carry into the future, we carry for some sort of reason.
Well this is interesting question
a) on linux, you can mount anything anywhere, even multiple times – so where is it mounted is up to you – / can be one disk partition and /home another and /tmp can be ramdisk – DOS was running in machines with 2 floppy drives, than 2 floppy drives and one DISK – UNIX was developed on more complex machines with multiple disks form the start.
b) /dev … those are devices – every linux distribution will have /dev/sda (‘s’ here stands for SCSI, not SATA) for your SATA disk, and /dev/sda1 will be first partition on that disk, if you have 2 SATA disks you will have /dev/sda and /dev/sdb and so on, nvme has a bit different naming convention but the same applies
now as every linux sysadmin knows, this is a trap – what is “first SATA disk”? Even in DOS, what C:\ may be unclear for some – it is first partition on master disk on first ATA channel. But not first physical partition, but first record in partition table (this fact was used by various programs, that allowed to install multiple windows instances and switch between them during boot)
this is where these long cryptic paths are introduced – they are actually symlinks – and are used to more precisely identify a device when you have multiple copies of it. Not only disks, but usb2serial ports too for example.
TLDR; computers now are way more complex than IBM PC XT and you need tools to deal with this complexity.
For sure, filesystem layout is really the root of everything wrong with modern phones. You can’t do anything without having to type a long string of gibberish.
I liked the Amiga system.
Device level naming.
Volume level naming (call it what you want).
Address it either way.
Everyone is happy (except that one guy..)
It always comes back to Amiga, somehow.
Huh. See, and here I thought that one of the first things that enticed me away from AmigaOS to UNIX (Solaris, on the school Suns, or NetBSD on my own A2000, at the time) was the unified filesystem layout. As soon as I made the move from removable storage to fixed disks and network file transfers, treating storage volumes as separate entities suddenly felt so pointlessly fiddly.
What I’d like is what the article pictured.
I’d like to repurpose my smart phone into being a gaming device for emulating older stuff.
That would be a pretty good use for it
<goes off to search for a project that’s already done this>
Try Retroarch
Excited to see where this project goes, might just get me over the motivational hump to really look at Rust properly.
“Redox is a promising project on mobile or desktop, and its development seems a much better use of time and effort than fighting over Rust in the Linux kernel.”
This.
Consider that Unix/Posix/Linux/…all the x’s are designed around the C language and its way of handing memory. Change that model and you kill all fundamental assumptions about how you interface with the kernel (or at least you kill many of them and the rest leave with a severe limp).
To really take advantage of a different way of dealing with data, the kernel needs to be designed with that model baked in. If the model has merit and the kernel designers are up to it, the result should be far simpler and more robust than what you’d get by trying to transmogrify a fundamentally different thing into something it was never intended to be.
In the worst case, they end up re-inventing the wheel and learning that there were good reasons for the older designs. In the best case, the model proves itself and the new OS is robust (I almost wrote “superior” but that gets into the trap of believing that there can be only One).
This is the first I’ve heard of Redox, its nice to see the effort. Definitely worth checking out.
As an old C/Unix hand, I’m firmly biased by decades of accumulated knowledge in that field. Maybe I can’t warp my mind around some newfangled way of doing things… let’s see.
“Redox is a promising project on mobile or desktop, and its development seems a much better use of time and effort than fighting over Rust in the Linux kernel.”
I agree in spirt. If you want to use Rust, then write you own OS if you think Rust OS will be the salvation of programming. Sounds good, but… The problem in this approach is supporting all the hardware out there…. Redox has got a LOT of catching up to do…. Linux has had the privilege of accumulating hardware drivers written in C for many many ‘years’ now. You can throw Linux on just about any desktop/laptop/server/sbc and the hardware is usually supported out of the box. I think that is a major reason for pushing Rust into Linux from the edges working inward. In a way this approach makes as much sense (or better?) as going the Rust OS from scratch approach.
Adding to what the other person said:
Rust doesn’t have a fundamentally different memory model from C. It’s meant to interoperate. Most common C data structures can be passed to Rust and used verbatim, without needing to be copied or converted*.
However —
Rust only gives strong memory safety guarantees for Rust code that calls other Rust code. Wherever your program interacts with something else — whether it’s bare metal hardware, or C — those guarantees are lost at the boundary. If a Rust program corrupts memory, the issue is practically guaranteed to be at that boundary.
So, Rust software benefits from having a clear interface where it interacts with “other stuff”. If your program is a homogeneous mixture of Rust and C, there isn’t much of a point. However, it makes total sense for something like device drivers (which is what Rust is currently used for in the kernel).
The compiler can make no guarantees that your driver will correctly interact with the rest of the kernel, but it will guarantee that your internal logic doesn’t corrupt memory.
Notably, doubly linked lists are very difficult in Rust. Also — using C structures/functions in Rust requires some boilerplate, but it doesn’t compile to anything. It amounts to: “I swear to God there’s a struct with this layout at this address; please stop yelling and just trust me”.
*heterogeneous.
I copied all the above comments into Grok as input and asked it to come up with a new comment. 🤣
“The POSIX vs. Windows filesystem debate is a bit tired. POSIX’s /dev maze and Windows’ drive letters are both relics, tied to ancient hardware constraints like minicomputers and floppy drives. Sure, POSIX’s unified file abstraction was clever for the ‘70s, but in 2025, with cloud storage, distributed filesystems, and containerized apps, it’s clunky for users who don’t grok inodes or mount points. Windows’ C:\ is no better—drive letters scream 1980s DOS, not modern NVMe or S3 buckets.
Link Shell Extension is a solid hack, making NTFS’s hardlinks and junctions usable via a slick shell interface, but it’s still papering over a core issue: both systems burden users with outdated mental models. We need a new abstraction—think a tagged, queryable data continuum, not rigid hierarchies. Redox’s experiments with a from-scratch kernel and filesystem are cool here; they’re poking at what a post-POSIX, post-drive-letter stack could be. Even if it flops, it’s sparking the right questions.”
There was WinFS, which had the problem that if people can’t handle a straight hierarchical filesystem, they CERTAINLY cannot handle a query-based system.
Our current filesystems get close to minimum viable product. Maybe not optimal, but viable. Almost any additions might make specific workflows easier but risk suffering impedance mismatch issues when your needs don’t fit the specific design constraints. It’s better to have a subsystem which poorly fits your needs than to have a subsystem which actively fights you.
“We need a new abstraction—think a tagged, queryable data continuum, not rigid hierarchies.”
Nope.
neither C: or /mnt are going anywhere soon – the fundamental issue here is that users think of information – on computer or not – in a hierarchical manner. You can’t abstract that away because that is how humans think.
We put things in lists, and sort things into categories, and put those things into categories. And we have been doing that on paper well before computers arrived.
So efforts to always store things not that way are doomed to fail (outside specific use cases) – because as soon as we have more that a couple of things that is how we want to organize them – unless there is a good specific reason not to…
What if someone invented a filesystem that stores all data in MySQL? Something like forum threads on phpBB by Przemo but improved for modern use cases.
That was already done to death with FUSE on linux. That was popular project at one time (though, usually used sqlite, not myslq).
i agree with you and they’ll pry the traditional filesystem out of my cold dead hands. but the gmail sales pitch eventually got to me. i don’t know if everyone else remembers the early days of gmail but it wasn’t sold as just “google monopoly expands to email”, it had the promise that you would no longer dispose of your email by tossing it into various folders. you would just stop reading the email when you were done with it, and whenever you wanted it back, google would easily surface it through some non-hierarchical or implicit-hierarchical search mechanism.
i still do it the old fashioned way, i save emails into a bunch of folders. but a big project i’ve been working on has a social component where it’s very valuable to remember where i left off with a certain correspondent, or sometimes i’m looking in past emails for a bit of data to cite somewhere else. and the hierarchical mechanism i’ve chosen is revealed to be unsuited to this task. too many emails meet multiple criteria and it winds up looking random which folder an email goes into. so i wind up doing grep foo Mail/* on a regular basis — searching across all the folders at once. but grep, of course, doesn’t know more than one line at a time so if i want to “find all occurrences of foo in an email from a member of organiation bar”, it can be pretty tedious. and every global grep winds up spuriously matching a few lines in mime64-encoded gibberish. if i knew ahead of time which kind of searches i wanted to do, i could do it with pretty simple scripts (or, like LordNothing says, i could put it in a relational database).
but fundamentally i don’t know if data really is hierarchical by nature. it’s clearly a valuable paradigm for managing complexity but i’m not convinced that a pile of searchable data isn’t what people actually want most of the time.
That’s only sometimes true. Sometimes, people want the same data organized in different ways.
Photos are the prime example. I might want to look at photographs by date, or by location, or by album — where multiple albums can contain the same photograph.
Music and movies, too. My DJ software (Mixxx) uses a database behind the scenes and provides all sorts of ways to organize.
Another example is /dev/disk/by-[id, UUID, etc] in Linux. The kernel provides multiple symlinked views of the same objects.
The truth is — the world is messy, and different problems require different solutions. A lot those solutions currently involve providing views into non-hierarchical data in a way that looks like an old-school FS (think: BTRFS snapshots, /dev/disk/), or ditching the filesystem and using an application-specific database (Google Photos, Mixxx).
I’m hoping that someday, filesystems will natively provide database-like functionality, so that software like Mixxx can store everything it needs directly in the FS and interoperate better with other programs.
Who uses
/mntfor ANYTHING anymore? Removable drives mount in/media, and everything else is mounted somewhere in the/hierarchy. The Filesystem Hierarchy Standard describes/mntas a location for “temporary mounts”, which these days makes it just as much of a relic as/srv.“But thanks to Rust, you can rest assured that login screen hasn’t got any memory leaks!”
You sure about that?
https://lunduke.substack.com/p/massive-memory-leaks-in-system76s
yeah i cringed at that too. i’m skeptical of the hype but i believe that rust is effective at preventing buffer overflows, writes into free()ed / out-of-scope memory, NULL / uninitialized pointer dereference, that sort of thing. but so far as i know there’s no system that can prevent leaks. at best, you can detect them and alert the developer.
Agreed, and anyway part of the question with Rust isn’t just “can the code be memory-safe?” (yes), but “can it be memory-safe without too high a cost?” (hard maybe?)
The Rust coreutils project (far less ambitious than what’s discussed here) has been bit by some SEVERE performance issues in some tools. And while those usually come down to programmer error, and can usually be fixed, the point remains that even writing working, functionally equivalent programs in Rust doesn’t automatically mean they’re a good replacement for C code that’s been fiddled with and tweaked for three decades at this point.
Tragic use of unsafe
Lmao they got Uboot to maybe boot this on some Android phones? Wow call me when the real work starts then lol. Uboot runs on everything even when ya dont want it to, so that part took me aback. I am already over the rust hype anyway. It is the new “fetch” of HaD…
All this talk about file systems is obnoxious I think Linux is better. As you don’t have driver compatibility issues as much as you do on windows. I find that the file browser is easier on Linux then Windows. And coding on Linux is way better also if you need to find files in terminal ls helps a lot. There is greater compatibility with files and greater customization with Linux then Windows. As a dual boot user with kali Linux and windows I know. Also once upon a time had debian but soon realized Kali Linux was better.
All under MIT license. As if megacorps deserve yet another gift.