abarth

On iOS, the code that you've modified runs in an interpreter but code you haven't changed runs the existing fully optimized AOT code that's already in your app.

Thanks!

https://fuchsia.dev/fuchsia-src/development/hardware/intel_n... describes which NUCs are known to work.

CLOC says about ~1 MLOC of Rust and ~1.1 MLOC of C++ in https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

Fuchsia has a lot of Rust code. (Disclosure: I write Rust code for Fuchsia on a daily basis.)

There are some similarities. The main difference is that Wine is mostly in-process whereas, in this design is mostly out-of-process. I'll add a section on Wine to the "prior art" section of the doc.

Disclosure: I wrote the doc linked above.

The memory model is similar (a flat, linear address space). The OS APIs are quite different. Fuchsia's OS APIs are designed around an object-capability discipline. For example, almost all the syscalls take a zx_handle_t as their first argument, which means they are operations on an object the process has previously been granted access explicitly. In Linux, many OS APIs operate on the "ambient" environment rather than on a specific kernel object.

Disclosure: I work on Fuchsia.

Ah, I didn't realize the comment above was about the Eng Council. I'll raise the issue at our next meeting. Thanks!

https://fuchsia.dev/fuchsia-src/concepts has an overview and links deeper into the site for more detailed information.

I'm sorry, but I'm not sure what you mean by "this manifest." The blog post linked above was written by Wayne Piekarski, who is a Developer Advocate for Fuchsia. My role in the project is as a software engineer.

I look forward to it!

I understand where you're coming from, but that ends up being an inclusion issue in the project. I'm comfortable having my name and bio "out there" on the Internet, but I recognize that's a privilege. Not everyone who contributes to the project will be comfortable doing that.

Thanks! Yes, your ideas are alive and well in the project.

As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)

> Looks like you still cannot contribute without granting copyright ownership to Google

That is not accurate. Fuchsia uses the standard Google CLA:

"You do not surrender ownership of your contribution, and you do not give up any of your rights to use your contribution elsewhere."

https://cla.developers.google.com/about

"Rust is approved for use throughout the Fuchsia Platform Source Tree"

Skia is used by Chrome, Android, and Flutter at Google. I believe Adobe and Microsoft also use Skia in various products.

> Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications?

Yes. When creating the namespace for the child, the parent can map names to what whatever communication channels it chooses. If the parent wants to interpose on the child's access to "/dev/class/framebuffer", the parent could map that name to a channel that leads back to the parent.

> Can a process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?

Yes. That's useful for testing as well as for sandboxing.

When you create a child process, you can clone your namespace or you can construct a new one for the child.

(Disclosure: I wrote the doc linked above.)

The goal is to work with all iOS accessibility features. You can see our open accessibility issues here:

https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...

Notice that there are several open issues relating specifically to iOS accessibility features.

Accessibility is not complete yet, but it is definitely not forgotten.

GC

Instructions for getting and building the code are here:

https://fuchsia.googlesource.com/manifest/+/master/README.md

It runs on arm, arm64, and x64.

I'd recommend starting out with a small max-age value so that any mistaken records will expire quickly. (Disclosure: I'm a co-editor of the HSTS RFC.)

Chrome lets you see some of the HSTS internals:

chrome://net-internals/#hsts

There's no list of HSTS hosts because the host names are hashed on disk.

I just tested this on my laptop (which I keep on the stable channel). For some reason, I needed to reload the page to trigger the update check.

After the update to Chrome 28, I still had Flash 11.7. The blog post says that Flash 11.8.800.97 (the latest version) is rolling out via the component updater. I don't think there's any UI to trigger a component update, but it should happen naturally by itself.

Chrome 28 is available now on the stable channel:

http://googlechromereleases.blogspot.com/2013/07/stable-chan...

The update is rolling out gradually. If you would like to make sure you're on the latest version, you can select "About Google Chrome" from the "Chrome" menu on Mac. That will take you to a page that shows you which version you're running and checks for updates.

As the release blog mentions, the Flash update is rolling out via the component updater, which updates Flash independently of the rest of Chrome.

We're working through the prefixed features we inherited from WebKit:

https://groups.google.com/a/chromium.org/forum/#!searchin/bl...

Our approach is (1) to avoid adding new prefixed APIs and (2) to unprefix APIs when we're confident we're not going to cause compatibility problems.

Nope. Portions of the new WebInspectorUI are not even redistributable by third parties: http://trac.webkit.org/browser/trunk/Source/WebInspectorUI/A...

Their feedback is very useful to us as we iterate on the specification and implementation of CSP. (Disclosure: I'm an editor of the CSP specification.)

Peter's posts talk about everything that's going on in the WebKit project. The nightlies are just builds of Apple's Mac OS X and Windows ports.