Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redox – A Unix-Like Operating System Written in Rust

redox-os.org

Post reply on HN
Print view View original

151–160 of 215 posts

Re: Redox – A Unix-Like Operating System Written in Rust

#151

Post by bluejekyll »

grok2 wrote: post #146
bluejekyll wrote: post #143

Earlier quoted context omitted.

I'm working on something: https://github.com/bluejekyll/trust-dns I'm in the midst of implementing DNSSec right now, I've got RRSIG and DNSKEY validation back to the root now. I'm working on negative query validation right now, NSEC and NSEC3. Maybe a new release in a few weeks after that is supported.

Having used Rust for this, what are your thoughts about how Rust fares for such tasks -- is coding this in Rust better than using C; do you think you are having fewer problems in the end-product as compared to if you had used C. What are the kinds of issues that annoy you about Rust for this? Does the promise of Rust hold up? I am trying to see if I should use Rust for network programming and want to find out how Rus…

Honestly, comparing (safe) Rust to C is like comparing Java to C. Rust is a higher level language than C, so writing in Rust means (especially for security and network programming) means that I don't have to worry about initialization of memory, or allocation, or deallocation. That's where all my bugs came from in C.

In terms of use, I'd say there are still gaps in the number of available libraries, and features of those. I had to add some options to the OpenSSL Rust interface for instance. The non-blocking IO library, mio, is very solid and portable! And I want to play with rotor as a higher level abstraction.

If you use Rust instead of C, you will have fewer memory related bugs, and you have more portable code than std C. Rust makes happy low level programmers :)

Re: Redox – A Unix-Like Operating System Written in Rust

#152

Post by burfog »

burntsushi wrote: post #131
progman wrote: post #113

Earlier quoted context omitted.

Ok, seems I have yet a misconception about Rust's "unsafe".

"unsafe" is a superset of "safe" Rust. There are exactly 3 things you can do in unsafe code that you can't do in safe code: access/modify a global mutable variable, dereference a raw pointer and call other unsafe functions. That's it. See: http://doc.rust-lang.org/book/unsafe.html#unsafe-superpowers

No inline assembly? No ability to manipulate the bits of a pointer for stuff like alignment in a memory manager?

This is truly awful. It means you need to carry around a C compiler for the low-level parts. You could also use assembly, but then you're forced to write whole functions in assembly.

Re: Redox – A Unix-Like Operating System Written in Rust

#153

Post by cgh »

burfog wrote: post #152
burntsushi wrote: post #131

Earlier quoted context omitted.

"unsafe" is a superset of "safe" Rust. There are exactly 3 things you can do in unsafe code that you can't do in safe code: access/modify a global mutable variable, dereference a raw pointer and call other unsafe functions. That's it. See: http://doc.rust-lang.org/book/unsafe.html#unsafe-superpowers

No inline assembly? No ability to manipulate the bits of a pointer for stuff like alignment in a memory manager? This is truly awful. It means you need to carry around a C compiler for the low-level parts. You could also use assembly, but then you're forced to write whole functions in assembly.

Inline assembly: https://doc.rust-lang.org/book/inline-assembly.html

Arbitrary pointer arithmetic is also supported.

Re: Redox – A Unix-Like Operating System Written in Rust

#154

Post by chei0aiV »

amelius wrote: post #76
Manishearth wrote: post #34

Earlier quoted context omitted.

There's a bit more info here: https://github.com/redox-os/redox/wiki/URL

Very interesting. The only odd part is that the modules (drivers) themselves are not referenced by URL, but only by a simple word (in the example "port_io"). Also, I wonder how we could combine drivers. For example, (theoretically) instead of using "https" as driver, we could compose it as "HTTP over TLS over TCP", and change any of those subcomponents as desired. With URLs this might become clumsy.

Hurd translators can do that easily.

Re: Redox – A Unix-Like Operating System Written in Rust

#155

Post by hamburglar »

Sharlin wrote: post #30
iagooar wrote: post #19

Earlier quoted context omitted.

The name is quite clever, actually.

Yes indeed. * There's the Unixy "x" suffix * Iron turning to rust is a redox reaction * Redo means "do again (differently)" * Redox is an almost-homophone with redux meaning "revived"

Plus the "iron" / "bare metal" imagery for running directly on hardware as opposed to on top of some other layer. Redox puts rust on metal.

Re: Redox – A Unix-Like Operating System Written in Rust

#156

Post by poizan42 »

kbenson wrote: post #129
Animats wrote: post #126

Earlier quoted context omitted.

A web server gets big, complicated, has lots of add-on parts, and has performance constraints. Small routers, DNS servers, and BGP servers are small, closed systems that should Just Work. You want to get them working, lock the code into read-only memory, and forget them.

Just keep it simple and do HTTP/1.0, that's not all that complex.

If you are reading RFC2616 closely enough then you'll see that you don't really need to implement anything more complicated than what is in 1.0. E.g it technically requires you to support Keep-Alive, but it also states that the server is allowed to close the connection anytime it wants.

Re: Redox – A Unix-Like Operating System Written in Rust

#157

Post by burfog »

cgh wrote: post #153
burfog wrote: post #152

Earlier quoted context omitted.

No inline assembly? No ability to manipulate the bits of a pointer for stuff like alignment in a memory manager? This is truly awful. It means you need to carry around a C compiler for the low-level parts. You could also use assembly, but then you're forced to write whole functions in assembly.

Inline assembly: https://doc.rust-lang.org/book/inline-assembly.html Arbitrary pointer arithmetic is also supported.

Oh good.

There is something else missing AFAIK. It's not quite as critical, but it sure helps: bitfields

This was done rather badly in C, reducing portability by not letting the programmer fully specify the layout. Normally we mostly ignore portability; for x86 gcc and Visual Studio are compatible.

Imagine writing an x86 emulator which might run on hardware of either endianness. In theory, bitfields are perfect for implementing the GDT, LDT, and IDT. Bitfields are also great for pulling fields out of opcodes. Unfortunately, bitfield layout in C is undefined. The same trouble hits when parsing a file, for example a flash animation file.

One should be able to specify spans of bytes with chosen endianness and bit order, then subdivide each span into fields. Normally each bit should belong to exactly one field, with an error if violated, but it should be possible to define overlapping fields if the programmer insists. Fields should then be able to be joined into larger fields, even if they come from different byte spans. This allows handling split fields such as the x86 descriptor's base and limit or the PowerPC opcode SPR encoding.

Lack of bitfield support and lack of a "restrict" keyword are probably the two biggest things holding me back from rust now.

Re: Redox – A Unix-Like Operating System Written in Rust

#159

Post by ivanceras »

jaltekruse wrote: post #147
kpozin wrote: post #132

I've been looking through some of the kernel code [1] out of curiosity, and I'm very surprised to see that most components have almost no internal documentation — minimal file and class comments, and even fewer inline comments. Is this typical of code for something as complex and central as an OS kernel? Are the developers planning to go back later and add documentation, or is the expectation that anyone who might ne…

I only took a brief look over the code to try to find what documentation is actually there, but I managed to find this https://github.com/redox-os/redox/blob/master/kernel/fs/url.... On your question of how typical a lack of system-internal documentation is in systems projects, the answer from my experience is unfortunately more common than it should be. There are a bunch of usage and design patterns that cannot be e…

In java, the jvm is the OS. Every object in Java is allocated in the heap, and doesn't provide developers direct control of a more optimized way of allocating objects. In rust, you can specify an object to be on the stack or on the heap, rust compiler is very smart and it knows where an object goes out of scope, thus not needed anymore and insert a code on that location to drop that object and free memory. Unlike in Java, which waits for the garbage collector to drop objects.

In a nutshell, java engineering effort is directed into the jvm(jit) to provide high performance when the applications are run. Rust engineering, on the other hand is directed on the compiler figuring out where and when an object is out of scope, no matter how complex it was attached to other objects, passed around multiple functions. It will figure it out.

Re: Redox – A Unix-Like Operating System Written in Rust

#160

Post by nickpsecurity »

poizan42 wrote: post #156
kbenson wrote: post #129

Earlier quoted context omitted.

Just keep it simple and do HTTP/1.0, that's not all that complex.

If you are reading RFC2616 closely enough then you'll see that you don't really need to implement anything more complicated than what is in 1.0. E.g it technically requires you to support Keep-Alive, but it also states that the server is allowed to close the connection anytime it wants.

What counts as a web server is quite a bit more complex, esp implementation. Even lighthttpd is non-trivial. The standards are for the tiniest core of the problem while leaving off significant issues. That might be acceptable in a web interface to trusted computer as Im advocating. It's barely a web server, though.
Post reply on HN