Hacker News Reader

Comment by jackpot51 | Hacker News Reader

I'm Jeremy Soller, the creator of Redox OS. Let me know if you have questions!

What are the things about Redox that aren't strictly Unix (or maybe POSIX) which you feel are marked improvements over Unix that folks with a general interest Unix & OS development should know about?

Has anyone looked into the viability of a Linux driver compatibility layer to help solve the problem of the lack of drivers?

For example, something like NDISwrapper allows you to use Windows network drivers on Linux.

Other prior art is DDE on HURD, FreeBSD drivers on Haiku, and NetBSD rump kernels.

FreeBSD has a pretty broad linuxkpi layer for Linux drivers on FreeBSD as well. E.g., the Mellanox FreeBSD NIC drivers are really Linux drivers running on this framework.

Things like this typically require a monolithic kernel.

NetBSD's rump kernel drivers might be portable to userspace

Not necessarily,

https://en.wikipedia.org/wiki/MkLinux

https://genode.org/documentation/api/dde_kit_index

What are the plans for bridging the ecosystem? - Is there a Linux compatibility layer? - Is there X11 support in Orbital? - How difficult is porting Linux apps? - I absolutely love the idea of using a memory-safe language for an OS, but realistically people will use whatever language they feel comfortable with for writing apps. - Is it possible to write applications in something other than Rust?

Hi Jeremy, I'd love to hear what your thoughts are on Rust after building something like this. As someone who's relatively new to both Rust and OS development, I'm curious what some of the challenges have been around core data structures often found in kernels where ownership can be ambiguous or complex, and developing without the support of a runtime/standard library. Has Rust passed the acid test of OS development in your eyes?

core is very comprehensive and alloc adds dynamic allocation once your kernel supports a heap. The complicated data structures in kernels are much easier to write in Rust, in my opinion. And you can be certain of their consistency when you have multiple cores running kernel code because of the ownership model.

I prefer doing bare metal development in Rust if possible

Redox looks very interesting. It seems one good approach might be to force new apps and drivers for Redox itself, but provide a VM environment that would run sandboxed Linux and other OS's securely. (Similar to the Qube OS idea.)

That way Redox could offer a considerably improved API and app development environment without worrying about backward compatibility, while being useful as a daily driver in the meantime.

Making the view releases button do something that isnt propping for a gitlab login, might entice people to make it past your homepage. Heck, add a "try it" button that redirects to the Book.

An update to our gitlab server changed the link, it's fixed now:

https://gitlab.redox-os.org/redox-os/redox/-/releases

Has Redox explored any unique, new, or forgotten techniques around security and data sharing between apps and users?

The microkernel seems long forgotten to me, it is critical for improving security

The performance problem has only gotten worse with time.

Modern CPUs have a rough time switching tasks. There are all those mitigations for meltdown and spectre. Even before that though, the situation with the TLB was ugly.

Limiting your data structures to ones that are friendly to message passing will really hurt you. Hacks to minimize the performance loss add complexity.

Fundamentally, glue isn't free. The parts may be simple, but the interactions are not.

Most embedded OSes for high integrity computing are microkernel based, then there is QNX, Minix running in legions of Intel CPUs, Android's workaround to have drivers as userspace processes with Android IPC as means to increase Android security and provide a proper driver ABI with Treble, and the ongoing push from Apple to move all kernel extensions into userspace, and then all those type 1 hypervisors.

Hardly forgotten.

Hardware IOMMU's have certainly made microkernels a lot more viable than they used to be in the past. You can actually place meaningful protection boundaries around core hardware drivers; they're no longer part of your inherent trust base, as they would be in a system where IO transfers can involve arbitrary memory.

Is Redox something that might be a viable daily driver at some point? I've been watching for a little while, and hope it gets there.

Also, in what way's does the project need help?

Edit: FWIW, I think this or something similar to it is the future of OS development.

At some point? Maybe. It would be in quite a long time. Right now writing drivers, porting software, and improving documentation are areas to help.

> At some point? Maybe. It would be in quite a long time.

I'll look forward to it.

> Right now writing drivers, porting software, and improving documentation are areas to help.

I'll take a look and see what I can help with.

How mature are the network stack and FS? I see a ZFS inspired FS named TFS, very cool! I’m assuming it can run headless but see it’s got a GUI from the book.

> FWIW, I think this or something similar to it is the future of OS development.

Disagree. It is mostly a Unix clone in rust with few novel concepts. Not that it is not important, and no offense meant to developers.

Perhaps GP was referring to microkernel design as being the future of OS development?

This is more what I meant. It just seems like Redox is taking the lessons we've learned over years of development, and being willing to break compatibility in order to implement them.

That being said, I don't know much about OS/kernel development.

So is Google fuchsia - it is even capability based. (But Google is not cool here around HN circles, despite their contributions to open source and fostering one of good engineering environments, they aren't cool because they don't shout some Privacy buzzword like Apple.) Also it is not written in rust, which is webshit-favorite-of-the-month.

Redox is still Unix like, it moderately changes the file paradigm. Microkernel Unix clones are not new. They mention Minix as inspiration while there is no mention of L4 which did lot of work in microkernel performance.

Google's fuchsia C kernel isn't particularly interesting IMO. its essentially LK (little kernel) but with 100s of syscalls.

A couple of weekends ago I was playing with seL4 on RISC-V and Rust under qemu, and it felt much better balanced overall than my recollections of LK.

What C kernel? It looks pretty much C++ to me.

https://fuchsia.googlesource.com/fuchsia/+/master/zircon/ker...

LK is C. It looks like they ported it to C++ for Fuchsia. https://github.com/littlekernel/lk/tree/master/kernel

Yeah, but Fuchsia is what OP was talking about and LK only existed in its original form during the early development of Fuchsia.

There used to exist a document about porting everything to C++, which I cannot find anymore.

At least it is capability based instead of yet another Unix clone. Not that any one of these are significantly better. But the rust crowd heralds redox as very innovative OS.

Ah, the traditional future of OS development.

40 years in the making.

But why do you disagree? What does your comment bring to the discussion?

Edit: removed italics tag.

It is not a whole lot of new concepts as rust crowd likes to portray it.

As opposed to Linux?

Who said Linux is a revolution in OS design? The big thing about linux was free availability and development model.

Are there tools to support static analysis and formal methods in Rust yet?

From https://news.ycombinator.com/item?id=21839514 re: awesome-safety-critical https://awesome-safety-critical.readthedocs.io/en/latest/ :

> > Does Rust have a chance in mission-critical software? (currently Ada and proven C niches) https://www.reddit.com/r/rust/comments/5iv5j7/does_rust_have...

FWIU, Sealed Rust is in progress.

And there's also RustPython for the userspace.

Any chance of adopting nushell as the default shell? You're already breaking so many other rules, and I see so much potential for it.

Redox also has it's own non-standard shell that has been worked on for a while, called Ion. I don't believe it's entirely POSIX-compatible, and has some neat features of its own. That said, it's certainly possible someone could end up porting over Nushell to work on Redox, but I don't think that's currently on their roadmap.

[1] https://github.com/redox-os/ion

The default shell is ion, a shell written in Rust and maintained as part of Redox. But I don't see it as important what the default is, so long as it is configurable.

We have ported bash and dash, so far. I think porting nushell wouldn't take much work

What alternative data structures do you have to use inside the kernel to provide good performance and satisfy the borrow checker without writing a lot of unsafe code?

What are the similarities / differences between RedoxOS and Google's Zircon kernel?

Reply on news.ycombinator.com