rodrigokumpera

ZStandard is... standardized under rfc 8878

Plus there's no discussion against zstd itself and its container format.

I'm an engineer at MSR working on VW, AMA.

Mono is MS.

Xamarin.Android begs to differ. It provides full integration and all we use from Dalvik are gc handles and explicit GC control.

Full Disclosure: I work at MS and I am one of the original designers of it.

MS engineer here, I work on mono.

Mono is not a strict superset of .net Core. We follow desktop more closely.

The extra APIs that are part of .net core, and are features on .net standard 1.6 will come to mono as we get the time to implement them.

Multi-threaded safety is simply due to JIT controlling the visibility of the newly compiled code. First flush, then make it visible for execution, can't go wrong with that and scheduling won't matter.

Things get a lot more complicated when it comes to code patching, but the principle is similar.

That approach is harder to use in practice that in sounds. It's not like people have not tried it.

The OS only let you alloc in large granules, like 4k or 16k, and the vast majority of the methods are significantly smaller than that, meaning a JIT must colocate multiple methods in the same allocation block or waste a significant amount of memory.

We could get around that by remapping memory between read/write to read/execute and have the OS solve the problem for us. Except for a couple of small details, modifying a memory mapping is very expensive and we're, well, in the performance business, and that mono is multi-threaded so one thread might be executing code from the exact page we just made non-executable.

This approach, IIRC, was tried by Firefox as it has some security advantages, but discarded due to the measurable performance impact - and they don't have the second problem as JS is single threaded.

Full Disclosure: I'm part of the Mono team.

Yes and no.

Core migration don't need to reach a global synchronization point, just enough so that the 2 cores in question agree with each other. This can be done without requiring global visibility of all operations of the source core.

That's a question for the libgcc team. I seriously doubt it to be slow enough to matter.

It's right on spot, if you're on H-1B, there's very little reason (or time) to switch jobs if green card sponsorship in not on the table.

Moving to a startup when under H-1B could be a very risky and possibly disastrous choice.

If those are companies that are illiterate on the most basic things, such the difference between an H-1B application and a transfer then there's a good chance they will fuck it up on the important parts.

Important things like H-1B renewal schedule, green card sponsorship, visa renewal expenses and so on.

You change jobs and the next thing you know is that you're stuck in the USA for up to 6 months because one of the overworked founders didn't apply for the renewal early enough.

The above is an easily manageable one compared to all the horror scenarios that a mismanaged H-1B immigration can be.

Maybe you'd be interested in mkbundle[1]. A tool mono has for close to a decade that allows you to bundle your app and all its dependencies into a single file.

We use it extensively at Xamarin with our platform.

[1] http://www.mono-project.com/archived/guiderunning_mono_appli...

Yes, the code is MIT licensed. Check it on github: https://github.com/microsoft/referencesource

In fact, for the past couple releases mono has replaced a lot of its library code with MS's quite successfully.

Full disclosure - I run the mono team at Xamarin.

The cheapest PhoneGap offering with support will cost you at least $249/year. And for that much you get No Guarantee support, which sounds quite odd.

Xamarin doesn't provide its products on Linux. But it doesn't mean MonoDevelop doesn't work there. The latest versions run on it, it's just a matter that we don't have the manpower to keep up with packaging.

On GTK+ 2, it's still the main toolkit used by the IDE, but on windows/mac some bits of the native toolkits are used to improve the user experience.

QT on iOS and Android means you get non-native UIX. So why bother with C++?

Disclaimer: I work for Xamarin.

Maybe it just means that Mono is much more well suited for games and embedded usage. Which arguably is the case.

Few things to notice here.

Mono's new gc is quite solid now. Mono for Android customers use it by default.

Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work.

Said that, if you compare it to other gcs offered on mobile environment we're doing very well.

Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable.

Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics.

BTW, I work for Xamarin but those are my personal opinions on the matter.

Would such patent make cancer patients have to pay royalties for their illness?