I'm not sure. I remember seeing an example in the docs, but I can't find it now. Actually the docs in general are a lot less opinionated than I remember them.

One thing that I did find is that the ion shell document mentions that it isn't a posix compliant shell because they would have had to leave out a bunch of features.

I wonder if someone's working on this from the other end. Like, instead of porting mrust from gcc to tinycc, port rust 1.79 from 1.78 to 1.1.

This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.

Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.

I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that's going to make their code so much cleanser and more manageable, I don't blame them for thinking it's all bullshit. It was last time.

I finally watched the talk today and that wasn't what I thought he meant. What I thought he was getting at was that the rust parts of the kernel interact with lots of other modules written by people who don't know rust. When those C modules change their semantics in ways that break the rust code, they can't go fix it because they don't know rust. In fact, whenever they make a change, they don't even know if they broke some rust module, because they don't understand the rust code well enough. And this is something that everyone is going to have to live with for the foreseeable future, because you can't force all those other kernel hackers to learn rust.

It's the same idea, and may even share some assets, but it's specialized to VR. It's kind of similar to the way that steam input and SteamVR input have the same basic purpose but are separate systems.

Besides the Steam Link device and the Steam Link android app, there's also an app with the same name on the Quest store that lets you stream SteamVR games from your PC.

I was about to write this exact comment.

Even if I hardly ever play standalone, it's nice to have the option.

Also the ability to wander around an arbitrarily large play space is nice too.

There are already libraries like clap that allow the developer to specify all their arguments including short and long variants and description strings. I think some of them will automatically generate --help based on the specified options. I could imagine a library that takes the same specifications and makes an interactive menu or a tui form out of them. It's an interesting idea.

I haven't seen that paper before. The ones I remember were blogposts or web pages. In fact, this may be what I was remembering: https://www.gnu.org/software/hurd/faq.html Particularly the part about what happened with the port to different microkernels.

IIRC NeXT and OSX use Mach, but they don't use it as intended. I think they're mostly a BSD kernel with Mach functioning as an interface to userspace.

Hurd actually used Mach as a microkernel, and moved most functionality to userspace daemons. This meant that Mach's performance issues,, at least the ones related to IPC, affected the Hurd a lot more than OSX or NeXT.

And yeah, I think developer interest was the biggest thing that held it back.

Both, I think.

It's built in top of Mach, which has some architectural issues that aren't fixable without a huge amount of work.

And no one's interested in doing that work because we already have Linux and Linux is fine.

There have been a couple of pretty good post mortems over the years. I think one of them is on gnu.org somewhere.

What did everyone pick up this sale?

I got Underdogs, House of the Dying Sun, Cold Start, and Titan Station.

That's me set for the rest of the year, probably.

It does have pancake lenses, instead of the fresnel ones in Q2. It also has continuous ipd adjustment, not the 3 settings like Q2.

It is a lot more expensive, though, and it has nothing on the Q3, so unless you're allergic to Meta, there's not a lot of reason to get one.

Ive been using it for several years. I hardly think about it at all, which is pretty high praise.

I'm looking forward to hearing from people how own both this and Eternal Starlight how the two compare.

I mean I'm pretty sure Home world has more budget and is more polished, but I'm curious about differences in approach, any design decisions where one game chose better than the other.

It's also worth noting that before bevy, there was a rust game engine called Amethyst, which was planning on using a scripting language for gameplay code. Not having to use a scripting language, but getting to use rust instead, was one of the big selling points of Bevy overr Amethyst.

You can charge for FOSS, but you can't prevent the first person who buys your software from sharing it with everyone else for free.

Sometimes I'll start up ConnectBot, which is an android ssh client, on my meta quest. Then I connect to my laptop and attach to a running tmux session so I can use the laptop keyboard but see the text in a virtual window.

My actual laptop setup is pretty boring though

The Koka language has a stated goal to be as simple as possible. The language definition even has something like scheme's "feature on top of feature" verbiage. However it's a very different language than you're thinking of.

Haskell is simple in some ways and complicated in others.

It doesn't have optional or named parameters. There are no objects or methods. No constructors. It doesn't distinguish syntactically between procedures and functions. There are no for loops or while loops. && and || aren't treated specially. It doesn't even have functions with more than one argument. Every function takes one argument and returns one result.