Hawxy

> who exposed a so-called war hero as someone who actually committed war crimes.

Worth mentioning that this wasn't David's intentions. He leaked the documents as he thought special forces soldiers were being "unfairly" restricted via tighter rules of engagement & defense oversight in order to protect civilians. He wanted the ABC to tell everyone that special forces were being kept on too tight of a leash, not report on war crimes.

> Ever since, the Chrome plugin takes forever to login.

This isn't my experience since the recent update that shows up a mini-login panel when trying to sign in. The old experience that opened the desktop app first was fairly slow.

Your points are covered by League's blog post that goes into the underlying reasoning: https://www.leagueoflegends.com/en-au/news/dev/dev-vanguard-...

At least in terms of video games investment, Tencent is known to be very hands-off of the western companies it owns and is often seen to be a better option vs some western conglomerates. Ubisoft turning to Tencent to help it fight off a takeover attempt from Vivendi is a pretty good example.

Vanguard itself is developed by a US-based team and they've stated that they have very little to do with Tencent's anti-cheat team (Tencent uses its own solution for the CN region, including for Riots game) beyond sharing cheat samples.

Sure, you can use it like that, but it's not considered good practice. I think the context missing here is that most modern C# applications are going to be async all of the way down. The entry point can be async. Background service abstractions are async. Your API endpoints in ASP.NET Core are typically async as you're going to be calling some async I/O anyways (database queries, HTTP clients). There's no benefit to writing something in the old callback model when the rest of your code is async/await anyways.

Is "creator of nuget" in his twitter bio just an inside joke?

> why not

Because ContinueWith is considered antiquated in modern C# and shouldn't be used for a multitude of reasons? https://medium.com/@joni2nja/why-you-should-not-use-continue...

The article continues with all of the different ways you could do sync-over-async and all of them have downsides. There's no "good" solution that could be recommended.

The community consensus is to do `GetAwaiter().GetResult()` and simply accept it's not an ideal usage.

I've had this linked in my work's C# guidelines for a while. It's a very useful authoritative source whenever someone decides to do something weird in async land.

FYI this is written by David Fowler, who is personally responsible for the creation of ASP.NET Core, SignalR & Nuget (maybe?).

> Do packages with external C / C++ dependencies include binary blobs for platforms or compile them on the fly, or do they need to be configured for each platform?

They usually bundle them in. For example the SQLite packages are bundled with ~23 different native binaries for all of the platforms it supports, and they'll be output to the right place as part of the build process. There's nothing you need to configure.

For licensing or packaging reasons this might not apply to everything (ie ffmpeg).

> Now I just use JObject as the parameter and deserialize at the top of the controller method.

This might be worth fixing, you're paying a performance penalty by needing to do intermediary deserialization and by using the old Newtonsoft serializer (STJ is significantly more performant).

Request validation (ie with FluentValidation) would shake out any deserialization mistakes.

> I've also run into some ecosystem issues where the OpenAPI codegen was a bit lacking and wouldn't actually generate code that works

Try Microsoft's new Kiota generator, its works a lot better.

> it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms.

As a default rule, any package you see that targets ".NET Standard 2.0" or ".NET 6+" is using the modern SDK and very likely works across all platforms. This will cover the vast majority of open source packages created/updated in the last 5 years. If a package only specifies '.NET Framework' then it'll be windows-only. Modern packages that are tied to a single platform will likely be named as such and will specify a target that locks it to that platform, ie `net8.0-ios16.0` for iOS.

> Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir.

For ImageMagick specifically, there's a purist C# replacement (ImageSharp) that avoids the dependency on System.Drawing.

> A lot of times the bug is the developer assumed everyone uses Windows.

I can't say I've encountered this in years, most libraries are cross-platform out of the box with support for the major .NET 6+ targets (Windows, Mac, Linux).

FYI github already supports using passkeys as a combined login/2FA source. I haven't used my 2FA codes for a while now.

> What's worse, type checking was largely an afterthought in the development of Vue

I'm not sure what you mean. For Vue 3 it was a priority and extensive work went into exposing types that would make it easier for IDE tooling to integrate. Features like the `defineProps` macro are specifically designed to make TS development easier.

> is actually conditional upon the building industry getting their act together

I don't think this is correct. The SafeWork report (recommending a complete ban) superseded this health report, and the ministers appear to have aligned on the SafeWork recommendation.

It's very much worth reading the full reasoning within the SafeWork decision (page 56):

https://www.safeworkaustralia.gov.au/sites/default/files/202...

SafeWork's view is that the industry is too much of a non-compliant mess to recommend any other option apart from a complete ban.

> TPM2.0 is used only by bitlocker

This isn't true at all, Windows Hello uses it as a secure credentials store.

Just to follow up if anyone reads this far down, an interview with David Weston from Windows 11s release also validates what I've said in this comment chain:

https://www.techrepublic.com/article/windows-11-understandin...

It's a whole list of reasons, not just this. I was finally able to find the interview with David Weston that goes over all of the requirements:

https://www.techrepublic.com/article/windows-11-understandin...

> He says absolutely nothing about DCH and doesn't give any explanation for the minimum hardware requirements

The hardware security baseline is one of the first topics he covers as part of Windows 11 security strategy, with mention given to features that require hardware support and how they intend to enable these by default going forward as not doing so was a failure of the Windows 10 strategy. He even mentions "virtualization extensions" aka HVCI-related features which would be non-performant to enable by default in older hardware.

How exactly would a strategy of enabled-by-default work if the hardware wasn't there to support it? You seem to be looking for some hard "gotcha" statement to refute your argument instead of considering all of the information available in front of you.

> No, they didn't even make DCH a requirement;

By setting the minimium CPU requirement to systems that use DCH drivers, they effectively did.

> Core isolation support is not a distinguishing feature between (say) the 7700HQ and 7820HQ, as far as I know.

That's not the issue here. The 7700HQ lacks Trusted Execution support (aka TPM), whilst it's included in the 7820HQ, thus it does not meet the minimum requirements.

> electronic trash now because they might add something that helps security years later?

No, it's giving people the heads up that Windows 11 security strategy requires these features and gives people & companies time to adapt. For example, motherboards now ship with TPM 2.0 enabled by default, so as Windows 11 rolls out more features that require it (some aspects of Windows Hello already do), users aren't stuck with a system that needs a BIOS update or are unable to use the new features. Windows 12 will very likely make these requirements hard-enforced rather than soft-enforced and thus it'll make the 11-to-12 upgrade a smoother experience.

> I find it quite interesting how they whitelisted their own Surface devices but not, say, Thinkpads, despite them having the same CPUs

Because Lenovo did not bother writing DCH drivers, given DCH drivers are the baseline requirement.

> Could you explain in what way "DCH driver support" is a "hardware security mitigation" as you wrote?

I was recalling a 2 year old blog post in my head, but the point is still that much of the requirement is around baseline security. If you watch the video I linked, the speaker does go over all of this.

> basically let hardware vendors decide which otherwise-capable CPUs they'd like to make obsolete through software updates?

I'm not sure what you're getting at. DCH drivers were already the default for current-gen hardware _before_ W11 even came out, W11 just made it a requirement. Vendors clearly aren't going to go write some greenfield drivers for a years-old 6th gen intel product just to support W11, as those devices will be 10 years old by the time W10 support ends.

> note that the OS isn't even turning on the CPU features they require by default

Note that you're still referencing a blog post from 2021. W11 22H2 enables core isolation by default for new installations, and HVCI is enabled by default when using the Windows Enterprise security baseline.

https://techcommunity.microsoft.com/t5/microsoft-security-ba...

The last paragraph is a little strange as Microsoft explained its reasoning the day before:

https://blogs.windows.com/windows-insider/2021/08/27/update-...

It only added 7th gen processors that have DCH driver support, which is the absolute minimum baseline for W11 support.

> just to make existing CPUs obsolete and keep Intel in business.

Bizarre take. It's not random, it's specifically CPUs that support modern hardware security mitigations + features.

There's a pretty great talk from Bluehat a few days ago that goes into why Microsoft is doing this:

https://youtu.be/8T6ClX-y2AE

> That includes the .NET Core BCL, AFAIK.

The BCL was completely annotated with NRTs for the .NET 7 release, minus some #nullable disable spots.

Yep! We use this to test our webhook integrations locally. Works great.

> Maybe we are too small but Datadog is one of the few vendors which we haven't been able to negotiate down in years.

We spend a few thousand a month with Datadog and our account manager reaches out every quarter to adjust our monthly commit up/down which provides a 20% discount (I think) or so off from the website prices.

Composition API has the best Typescript support available in Vue 2. It's supported out of the box in 2.7, and a plugin in previous versions. The decorator syntax is unsupported in Vue 3 and shouldn't be used.

> vue-class-component with typescript

I was using this but immediately saw the writing on the wall as soon as the Composition API came out with its far superior typescript support. Converted our greenfield Vue 2 app over to the new API within a few weeks which turned out to be the correct decision.

Unfortunately, unless you were following Vue development very closely this would've slid by.

Are you sure vue-class-component 8.0.0 RC1 doesn't work? I see it was in development for v3 before being discontinued.

CDK also works with Java or Python.