xmodem

Apple's policies prevent using JIT compilation, they don't ban VM's outright.

Sentry does a lot more than tracking errors - presumably most of those transactions are 'breadcrumb'-style events.

This is exactly my point - it successfully accomplishes a very specific task, in a way that is fragile and context dependent, and completely fails to handle any errors or edge cases, or reckon with any complexity at all.

I was about to down-vote you, but that would be unfair, as this has roughly the typical level of correctness of most bash scripts.

What does this gain you that you can't already do with `extern "c"` functions from rust?

Yeah, exactly. Here on a website called 'Hacker News', we're only interested in projects when they're feature complete and mature enough for production deployment, not before. (/s)

I spent four years working at a European fintech that serviced millions of end-users, and we had a self-service GDPR portal for users to export or request deletion of the data we had on them. (In some cases we were required to hold onto certain data due to other laws). Any feature that stored new user data had to get integrated into the tool, and then signed off from legal and the team that maintained the tool.

It got very little usage - maybe a few hundred to a thousand requests per year IIRC. I shudder to think what you could have been doing that would attract that volume of requests. Was it Clearview AI?

The US is not the only government with sway over US tech companies, and the OS market is now substantially more diverse than when secure boot on x86 was first introduced ~15 years ago.

Never say never, but I just don't see how the option for one to boot an alternative OS on the vast majority of commodity hardware is going to be rolled back any time in the foreseeable future.

I think that finding and fixing this many vulns is a worthwhile achievement, no matter how they did it. But it does detract from the quality of the article that they are pushing CoPilot so heavily.

Thanks for the explanation. So you are using virtualisation-based techniques. I had incorrectly inferred from other comments that you were not.

I skimmed the paper and it suggests your hypervisor can work without CPU-based virtualisation support - that's pretty neat.

Many cloud environments do not have support for nested virtualisation extensions available (and also it tends to suck, so you shouldn't use it for production even if it is available). So there aren't many good options for running containers from different security domains on the same cloud instance. gVisor has been my go-to for that up until now. I will be sure to give this a shot!

What underlying primitives are you relying on to provide isolation, if not linux namespaces?

How does your approach compare to Google's gVisor?

The Azure portal has some nice ideas - in theory, being able to divide stuff into "resource groups" works a lot better than the AWS approach of "divide resources that should be isolated from each other into separate sub-accounts".

In practise, even the good ideas are implemented poorly.

I think that the Van Halen Brown M&M anecdote is relevant here.

> and the Web PKI doesn't just mire itself in squabbling that blocks progress on actually meaningful issues.

In your view, are there any meaningful issues going un-addressed currently?

Looking at the original report ( https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 ) I can see a couple of questions that DigiCert appears to be avoiding:

> The public record of Alegeus Technologies LLC v. DigiCert shows no attempt by DigiCert to contest the court’s order prior to the end of its preferred period of nearly 120 hours, even though such a motion could have freed DigiCert to revoke the certificates days earlier.

and

> The other question in comment 28 was for the language establishing DigiCert’s right to revoke Alegeus Technologies certificates. DigiCert has waffled on this point, first implying that this language was to be found on its website but later refusing to confirm that the language on the site applied to Alegeus Technologies at the time.

SPECULATION: Digicert may have offered special terms to Alegeus, and possibly other customers. They may have chosen not to dispute the TRO in court because they did not have grounds to do so under those agreements. They may also have included confidentiality terms in those contracts that prevented them from speaking about it.

OPINION: I am surprised that the forum allowed the issue to be closed without the above quoted questions being satisfied, though it is possible they are addressed elsewhere, I have not done a complete reading of all the linked issues.

EDIT to add: DigiCert has a response in a different thread here: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43 that would appear to contradict my speculation. Specifically

> Even though DigiCert’s TOU and MSA prohibited Alegeus from taking the action it did, once it filed for a TRO and the court almost immediately granted it, DigiCert’s hands were tied

Is there supposed to be something useful in that response? Cause I don't see it.

A RasPi with composite output, coupled with an RF modulator should do it. Just don't tell the FCC.

Could you cite something that goes into a bit more detail?

The only claims for country-of-origin I see on that page are the "US-Sourced Materials" heading which clarifies "..using aluminum sourced from US companies."

330 EUR is roughly reflective of the street price of the B580 in Europe.

For example:

https://www.mindfactory.de/product_info.php/12GB-ASRock-Inte... (~327 EUR)

https://www.overclockers.co.uk/sparkle-intel-arc-b580-guardi... (~330 EUR)

https://www.inet.se/produkt/5414587/acer-arc-b580-12gb-nitro... (~336 EUR)

Depends why you want to get users upgraded. If you want your users to be upgraded so they have access to security improvements, and those security improvements require TPM 2.0 or whatever, then allowing upgrades on older systems without TPM 2.0 rather undermines the point of getting those users upgraded.

At no point in history has using a 10-year-old PC been as viable as it is today.

As of Windows 11, you can use Bitlocker on Windows Home.

(Personally I think you probably shouldn't bother with it unless you set a boot PIN, which still requires Pro to be allowed to change the right group policy settings.)

I don't think there's anything going on here other than general corporate ham-fisted-ness.

* Microsoft believes the improvements in windows 11 provide genuine benefit to their users.

* Microsoft doesn't want to maintain their older OS forever.

What we are seeing play out however is that the consumer / small business market either does not understand or does not care about those benefits. I don't see any viable end-state for this other than Microsoft relaxing the requirements for Windows 11 or extending the end-of-support date for Windows 10. Based on this action my money is on the latter.

You can install Windows 11 into a virtual machine with a virtual TPM, and it will detect and use the vTPM the same as it would a physical TPM on real hardware.

I think it's more looking at the past with rose-tinted glasses, and forgetting that some of the things that have improved over the past decades wern't always that way.

I too have nostalgia for the days when my start menu didn't phone home to microsoft, and focused on making my computer useful rather than trying to sell me stuff. Would I give up things like hi-dpi support to get that back? Hell no.

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

Yeah, like they've done to TSMC over the past decade. (/s)

They probably know CoPilot as the thing Microsoft is trying to shove down their throat...

Not OP, but I briefly seconded to a team that used Scala at a big tech co and I was often frustrated by this feature specifically. They had a lot of code that consumed implicit parameters that I was trying to call from contexts they were not available.

Then again I guess it's better than a production outage because the thread-local you didn't know was a requirement wasn't available.

I think the matrix shown in the github issue is for Windows support, which is much better: https://rocm.docs.amd.com/projects/install-on-windows/en/lat...

Having said that, on the weekend I set up ROCm on Linux on my 6800XT and it seems to work just fine.

Cursor does not have a bug bounty though, and its hard to see how this constitutes anything other than a direct attack on them, their users, or both. "The incentive structure made me do it" does not justify acting like a criminal.