scudo has been the default allocator for Android since Android 11, and we are hoping to make it mandatory for the few remaining places that don't use it. Using an allocator without memory protections in 2026 (especially after we have closed nearly all known performance gaps with jemalloc) is really not a great choice.
Actually, it's complicated stuff pulling together two data points:
1) 2/3 of people are confident contributing in 2 months or less
2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months
Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.
Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...
That's exactly right. Today, the focus is on making it possible to use Rust to write pieces of the Android platform itself.
Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.
In practice, people consumed the keynote/talk content in a variety of formats (streamed, recorded, and in-VR) and there was a fantastic networking and meeting-new-people effect in the poster, hallway (post-talk), and demo sessions. There's a bunch of formal research that was done there along with post-conference surveys to track down specific data (e.g., how many new people did you meet?) but it will take some time for those teams to rigorously collect & report.
Hi! As we mentioned in the recent Quest release blog post, https://blog.mozvr.com/firefox-reality-for-oculus-quest/, we have some designs for multi-window support and synchronization of content between platforms. We're still working on options around tabs / additional content beyond the number of windows you have open, alongside our really awesome Seattle-based design partners, Podipo: http://podipo.com/
Once we have some concrete designs, we'll have issues open and on our public roadmap for comment and we often have early builds available in our releases page for sideloading if people are interested in testing and giving feedback.
Thanks! We also find that a lot of our users really like watching 360 or even 2D videos, taking advantage of the ability to resize the screen to get their own personal theater.
Right now, we only have Firefox Reality available for standalone VR headsets, but we're bringing the experience to desktop VR and a variety of standalone AR headsets in the second half of this year.
Unfortunately, we don't currently support phone-based Daydream or Gear VR devices. There's both a bunch of extra work to support all of the phone in/out/notification lifecycle scenarios and we have a pretty small engineering team and the long tail of phone/chipset-specific bugs is pretty substantial. We might evaluate support for it or Cardboard in the future, but for right now we're mainly focused on standalone headsets.
Thanks! We don't currently have a build of Firefox Reality available for desktop devices, but that work is currently underway. We announced it as part of our deal with HTC and are excited to show it off soon:
https://blog.mozilla.org/blog/2019/01/08/mozilla-announces-d...
If you're interested in this topic, I'd highly recommend watching Stephanie Balzer's sessions at the Oregon Programming Language Summer School on “Session-Typed Concurrent Programming”. The lectures are available online (https://www.cs.uoregon.edu/research/summerschool/summer18/to...).
Firefox Reality is the brand we're using for the suite of browser products across VR and AR devices.
Today, Firefox Reality is available for standalone VR devices (like the HTC Vive Focus) and is a native Java application that talks to the GeckoView library, which is made up of components from the mobile version of Gecko, the Firefox web engine.
Firefox Reality for desktop will similarly be based off of the Firefox Desktop product pieces.
Note that there's a bunch of "Servo inside" - from small Rust components to the Quantum work including the new CSS style system to the forthcoming WebRender component.
I don't have anything to announce today about a Firefox Reality-branded browser based on top of Servo.
On desktop, it means that if the user chooses to install the Viveport suite, that home experience and the suite will provide Firefox Reality as the default browser.
For all-in-one devices, Firefox Reality will be preinstalled and the default browser.
One of the biggest things we've found that people like to do in VR is private viewing. They'll collect links of videos all day and then come home to watch them on a "big screen" but don't have a laptop or TV that supports miracast, so use a VR headset. Or they like to watch twitch streamers or their favorite movie providers or just bounce around searching content.
As the hardware becomes more mature, we'll support more use cases, but we wanted to enable some compelling early use cases (especially voice search) and learn from users as soon as we could.
The issues with text input are a large part of why we added voice input even in our very first release! w.r.t. text rendering, we're doing a lot of fundamental work in rendering higher-quality text (you can't fix resolution fundamentals, but you can take into account the optics of the hardware better than we all do today), but nothing to announce there yet.
Yes, it's very barebones right now, as the team has been focused on getting performance great inside of standalone headsets. We've found from early adopters of 3DoF and 6DoF standalone VR headsets that media consumption (videos, news, twitch, etc.) is the primary use case and unfortunately pretty choppy and poor today.
We'll absolutely build out the UI and feature set (especially WebVR/WebXR!), but wanted to release as early as possible to transition away from private builds, design, and feedback to public conversations with users, developers, and device manufacturers.
And obviously we're investing in more the ecosystem - we need WebXR fully standardized and supported by all browsers, tools, engines, and frameworks. We also need lots of great content and social experiences that work on the web. We and others are investing a lot in this space - it's going to be an exciting summer!