Dart is core part of Flutter: https://flutter.dev

What makes you say it's being killed?

Before it was a part of flutter it went through years of silence and effective death.

From roughly 2013->2015 the mailing list was practically silent on dart.

Even then, the language got "rebooted" with a v2 in 2018 to try and stir up some new life in a language everyone thought was dead.

Android began restricting what APIs you could use in your app with Android 9: https://developer.android.com/guide/app-compatibility/restri...

Similarly, what is accessible from the NDK is limited: https://developer.android.com/ndk/guides/stable_apis

If you're willing to give it another go, you should try it in FEMU (our fork of QEMU): https://fuchsia.dev/fuchsia-src/get-started/set_up_femu

Something should be particularly wrong with the project if you have to use your own fork of qemu...

It's actually pretty standard to fork QEMU when you want to emulate a custom kernel/board. QEMU is a good common emulation platform, but in no way it can emulate correctly every quirks of a custom pci or even PIC device expected by the system.

I'm not expert in QEMU, but to my understanding, it would make sense to fork QEMU to support a new hardware/board/platform, but not so much to support a new "software"/"firmware" on top of an already existing and used board platform.

Why did Google choose to fork QEMU?

I had a brief look at the setup information and there’s nothing that makes it clear why there’s yet another piece of highly Google-specific (though presumably open source) software that people would need to learn to use while they learn about Fuschia.

FEMU is really AEMU, it forked from QEMU many years ago for a variety of reasons.

Today this configuration offers Vulkan support, which will hopefully make it's way back to QEMU eventually.

We use both QEMU and FEMU in our work, if you checkout Fuchsia you will find prebuilts of both in //prebuilt. QEMU provides broader control over hardware and broader emulation features, often useful to the kernel and driver teams. FEMU provides Vulkan graphics, more useful for teams working on GUI applications.

Any pointers to any hardware / dev boards that one can run fuchsia on? I remember seeing Intel NUCs being used in the past, is there a recommended hardware configuration for developers now?

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

Thank you!

Not to discredit the effort, but saying you've released your own fork of QEMU to run your own OS, creates an impression that you're perfectly happy to (prefer to?) create a parallel universe for yourself, with your own tools and its own ecosystem... Which will obviously all be controlled by Google. Not very good optics, IMO.

If you want promote Fuschia as a useful, general purpose computing platform (and not just an attempt for Google to avoid the GPL), you probably want to work upstream with existing projects to improve support generally instead of creating your own suite of forks.

As raggi mentioned above, you can use both.

The additional feature that FEMU provides us is Vulkan support, which allows you to interact with a GUI.

On the team, we use both. For example, I know many folks on the Zircon team prefer vanilla QEMU.

Yet Google's Browser engine is a fork of WebKit and surprise it is used in Chrome, Electron and QtWebEngine and everyone is using it.

As Fuchsia is highly dependent on Flutter and the whole ecosystem will be able to run Flutter apps on day 1, I would bet that this is going to be the Android replacement in this decade.

This is how old google would have worked. Now that google is all grown up they take a more cost conscious approach. How the mighty have not so much fallen, as sunk.

Stratechery has a good analysis of the "News Media Bargaining Code":

https://stratechery.com/2020/australias-news-media-bargainin...

Committing the faux pas of replying to myself, here's another take:

https://www.crikey.com.au/2020/08/31/scott-morrison-v-facebo...

My understanding is that they used to be, now they're all Cortex derivatives: https://en.wikipedia.org/wiki/Kryo#Kryo_5xx_Series

thanks!

I was really excited for this, I want to buy it and am willing to compromise for 1st generation hardware. But no NFC means it impacts my life substantially, from payments to public transport. I hope they reconsider the lack of NFC for the next generation.

Doesn't Sony use clang? My understanding was LLVM does a better job at optimisation than MSVC.

Working on a hypervisor, I see this. It mostly crops up as things like IPIs being more costly when nested.

Could you explain what you mean? I'd like to understand your point of view.

KVM can take better advantage of hardware acceleration than Xen. Xen requires a modified guest, which traps back to the host more frequently.

Is that true with the newer modes? https://wiki.xen.org/wiki/Understanding_the_Virtualization_S...

This is based on a cursory examination of [1], so I may be off-base. But Xen appears to rely on the host for many things that can be, and often are, hardware accelerated in KVM. Searching for CONFIG_XEN_PVHVM, it doesn't appear to cover much.

[1] https://github.com/torvalds/linux/blob/master/arch/x86/xen/