Redox OS Development Priorities for 2025/26

Posted3 months agoActive3 months ago

akyuu

97 points

25 comments

redox-os.orgTechstory

calmpositive

Debate

40/100

Redox OSOperating System DevelopmentSecurity

Key topics

Redox OS

Operating System Development

Security

The Redox OS team has outlined their development priorities for 2025/26, sparking discussion on the project's direction, security features, and technical decisions.

Snapshot generated from the HN discussion

Discussion Activity

Active discussion

First comment

Peak period

6-12h

Avg / period

Comment distribution25 data points

Loading chart...

Based on 25 loaded comments

Key moments

01Story posted
Sep 25, 2025 at 2:29 PM EDT
3 months ago
Step 01
02First comment
Sep 25, 2025 at 4:48 PM EDT
2h after posting
Step 02
03Peak activity
13 comments in 6-12h
Hottest window of the conversation
Step 03
04Latest activity
Sep 28, 2025 at 4:32 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (25 comments)

Showing 25 comments

shmerl

3 months ago

1 reply

Did they stop developing ralloc allocator?

surajrmal

3 months ago

1 reply

That hasn't seen any commits in 6 years.

shmerl

3 months ago

1 reply

It wasn't promising?

surajrmal

3 months ago

I believe the primary developer lost interest and no one else jumped in to take over. Not very unusual for a hobby project.

sapiogram

3 months ago

1 reply

How close is Redox to being able to run a web browser? I'd love to try doing real work on it.

dannyfritz07

3 months ago

1 reply

Don't know your requirements, but it does say "Working basic web browser with NetSurf" on the front page.

fabrice_d

3 months ago

It's a Rust based OS, so I expect people to try a Servo port instead!

newpavlov

3 months ago

2 replies

I still disagree with their decision to make libc THE system interface. I understand why it's important to provide a compatibility layer, bit, ideally, I would like to see a Linux-like (potentially semver-versioned) stable sycall API, or at the very least something like libsystem, i.e. a thin wrapper around technically unstable syscalls API.

gertop

3 months ago

1 reply

The fact that binaries tend to rot on Linux shows that maybe only having a stable syscall ABI the best way to handle things either.

newpavlov

3 months ago

The kernel ABI is notoriously backwards compatible (the famous "we do not break userspace" and all). The primary reason why binaries rot on Linux is GLIBC and other shared library dependencies. I still can execute a MUSL binary compiled more than a decade ago without any issues.

bfrog

3 months ago

The wild thing here with a microkernel is that the syscall API to the actual kernel should be theoretically really small right?

I get the various little services might change, but ultimately the kernel supporting posix like threading and memory operations should be mostly enough?

someguyiguess

3 months ago

1 reply

Hey redox team. Great work! Just wanted to point out, you wrote “attack of surface” Instead of attack surface. (On your home page https://www.redox-os.org/)

Also, I’m curious about the mention of drivers being in user space. Why would one want their drivers in user space? Wouldn’t that increase the attack surface?

ultimaweapon

3 months ago

1 reply

The benefit of drivers being in the user-space is it will limit the damage if that driver has vulnerabilities. The downside is, I don't think the performance will be great. The kernel already written in Rust and if all drivers also written in Rust with limited unsafe it should be almost impossible for vulnerabilities related to memory.

surajrmal

3 months ago

Performance can be fine for the vast majority of hardware. Some drivers may need to be colocated in the same process for performance, but your average PCI driver doesn't benefit at all from being in the kernel. People also underestimate what you can accomplish with an efficient async first shared memory based ipc can accomplish.

Security benefits of driver's being in user space become limited quickly if you lack an iommu. Additionally if it has to set things like voltage regulators or clocks it can easily put the system into precarious states. That said it's still worthwhile and has lots of other benefits.

foota

3 months ago

2 replies

> Hosted Linux for Driver Support

> In order to avoid porting thousands of device drivers, we would like to port QEMU to Redox, then run a stripped-down Linux to provide device drivers for less common and older devices. The interface between Redox and Linux-in-QEMU will be designed to be secure, so this approach should give us reasonable safety.

What a fascinating approach to this.

WorldPeas

3 months ago

1 reply

I used to do something very similar with old serial to usb adapters on a newer linux machine and a windows xp guest, it's more common than you might think and rarely unpredictable. The only concern to me would be supporting the incoming protocol as a passthrough (e.g. SCSI or Parallel) though they could just be handed over at the PCI/ISA level if that could be done.

foota

3 months ago

1 reply

How do you set up the interface "back" to the host?

Is it something like:

USB directly to the guest OS, then an emulated serial port in the guest OS back that the host OS connects to?

WorldPeas

3 months ago

1 reply

right, I have a hub that I connect it to because (shocker) my computer lacks any usb-a ports, so I just pass through the hub, and the serial children it contains are passed through. I just wish the same could be the case for firewire, I'm not willing to pony up the cash to make the dongle from hell (fw400-fw800-tb2-tb3) that may allow thunderbolt passthrough(?)

vetrom

3 months ago

1 reply

the prior art in this area is going to be PCI&USB passthrough implemented in qemu and xen, with related but separate in-guest or 'in-host' virtual devices representing the bridged device.

Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.

WorldPeas

3 months ago

I agree, as we get even further away from the 90s and 2000s and data gets more valuable, having mechanisms like this to access old systems is vital now that it's getting harder to make "missing link" type machines that have parallel/scsi/ATA/FW/etc. to dump old data

surajrmal

3 months ago

HarmonyOS NEXT already does something like this for driver support and I believe real phones already use it.

dcdgo

3 months ago

I'll be watching this project with keen interest!

pjmlp

3 months ago

Looks very interesting roadmap, looking forward to where Redox goes.

Regarding the server approach, I wonder if going for a type 1 hypervisor like Firecracker wouldn't be a much better approach than QEMU.

wolvesechoes

3 months ago

This is interesting project, but it saddens me that we are stuck with Unix-like for the rest of eternity.

mlinksva

3 months ago

Great to see in the priorities "sandboxing by default" (under desktop variety) and https://nlnet.nl/project/Capability-based-RedoxOS/ (under security).

View full discussion on Hacker News

ID: 45376895Type: storyLast synced: 11/20/2025, 12:32:34 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN