ngomez

Well, Buckmaster says both his and Alpöge's use of Codex was non-institutional, and OpenAI claims the right to train their models on inputs and outputs of non-enterprise users in their service policies [0]. So I'm not sure they were even promised that.

[0] https://openai.com/policies/how-your-data-is-used-to-improve...

You can grind some of the raw silicon out of a finished wafer but I don't think it'd be suitable to use in another batch of product. So instead of having the weights on the wafer like OOP was suggesting, hardware inference has been trending toward having a wafer of lots and lots of smaller cores with fast SRAM.

Using the space of an entire wafer for one chip would result in extremely low manufacturing yields. Even with state of the art silicon cleanrooms, there will still be defects in parts of the output.

With CPUs and GPUs, chip makers can disable faulty cores and bin them as lower SKUs to get some yield out of it. But if you're using an entire wafer to embed weights, and a speck of dust causes a printing defect that makes the weights wrong, the entire wafer is worthless.

The CloudFlare blog discusses that idea when they talk about having an "agent process" to hold cryptographic material, but they list drawbacks like having to develop two processes, implement a well-defined interface, and enforce ACLs. I'm not convinced that "developing two processes" is a reason not to do it, since the kernel is effectively just the second process now, but everything else makes sense.

It's unfortunate though since this is one thing I think Windows does decently well. The Windows crypto and TLS APIs do use a key isolation process by default (LSASS) and have a stable interface for other processes to use it [0]. I imagine systemd could implement something similar, but I also know that there are very strong opinions about adding more surface area to systemd.

[0] https://blackhat.com/docs/us-16/materials/us-16-Kambic-Cunni...

Interestingly, Microsoft has been trying to get ahead of this for a couple of years now with their National Partner Clouds program [0], which they describe as:

> designed for scenarios where full ownership and operational independence from Microsoft is required

In France's case, Capgemini and Orange have a joint venture to operate datacenters that Microsoft runs Azure and Office on top of [1]. Moving away from Windows and Teams would still reduce their dependence on Microsoft substantially. But if the core goal is to reduce dependence on non-European suppliers, I would be wary of the French government buying services from "Bleu" when it's mainly Microsoft and a couple of consultancies in a trenchcoat.

[0] https://learn.microsoft.com/en-us/azure/azure-sovereign-clou...

[1] https://www.capgemini.com/news/press-releases/capgemini-and-...

I've been trying uBO Lite myself for a few months, and anyone who uses YouTube will absolutely notice that it's worse at blocking. Lite tends to delay playback at the start of a video for as long as the blocked ads would've been, making the site feel slower, and once in a while an ad will slip past the blocker anyway.

Are you thinking of the Windows 3.00 Working Model?

https://betawiki.net/wiki/Windows_3.00_Working_Model

Not the whole thing: a lot of the Windows org chart is still under Rajesh Jha in Experiences + Devices, or scattered around Azure with Scott Guthrie. But they've already been pushing Windows Copilot and Bing Ads and widgets, so I imagine the plan is more of the same.

It's not just the kids growing up now. I'm sure plenty of millennials who watched YouTube when AudioSwap was a thing will recognize "Dreamscape" by 009 Sound System:

https://www.youtube.com/watch?v=TKfS5zVfGBc

I think the IPv4 "evil" bit [0] already does this :)

[0] https://datatracker.ietf.org/doc/html/rfc3514

Whether it's proper depends on who you ask but you can use the singular they.

https://en.m.wikipedia.org/wiki/Singular_they

Could you elaborate? AMD spun their fabrication arm off into GlobalFoundries a while back, and they seem to be doing okay. I thought that would be a good precedent for Intel divesting its fabs too, but I'd love to hear any counterpoints to that.

dupe: https://news.ycombinator.com/item?id=28501901

>if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data

It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.

I would hope Twitter already had this kind of setup, but their blog posts about this are all targeted at a more general audience, so I doubt we'll get that kind of detail anytime soon.

This is actually something I've played around with before. Unfortunately I haven't been able to find the free time to finish the project.

https://bitbucket.org/nsg-usa/constitution/commits/all

What's stopping Apple from selling the parts that they manufacture to third parties, though? If anything this is an argument for right to repair laws, not for manufacturers to further restrict how consumers can use their devices. The Massachusetts right to repair laws for vehicles already provided a good framework for such an electronics repair law.

That story sounds similar to Bezos' mandate in Steve Yegge's Google platform rant: https://gist.github.com/chitchcock/1281611

This doesn't work too well if someone adds Nine Inch Nails' Ghosts I-IV or Kendrick Lamar's untitled unmastered to their playlist.

Can you point to an example of telemetry that Windows is collecting that isn't documented and shown?

>they still refuse to publish the complete list of what is collected

They give you the option to fully inspect all the telemetry data your computer is sending, categorized by use.

https://docs.microsoft.com/en-gb/windows/configuration/diagn...

I'm also a TA for the class mentioned in this article. We teach Git and have a submission system where students submit patches based on skeleton code; students are required to make at least five commits. We still have a significant number of students who copy code, and while it does help with picking up on that kind of behavior those students also don't seem to care about the increased cost and will pad their commits anyway.

The issue of incentivizing students to guess-and-check when providing the test scripts upfront is, IMO, fixed by making the students write the tests themselves. This paper explains it pretty well:

https://www.cs.tufts.edu/~nr/cs257/archive/stephen-edwards/a...

Essentially the students would write a test suite and the grading framework would grade based on

1) Code coverage when running the student's test cases against an instructor's reference solution

2) Correctness of output: running student's test cases on student's code and comparing with output from running those test cases on the reference solution

3) Number of test cases passed in student's test suite

Also from the paper:

"All three measures are taken on a 0%–100% scale, and the three components are simply multiplied together. As a result, the score in each dimension becomes a “cap” for the overall score—it is not possible for a student to do poorly in one dimension but do well overall. Also, the effect of the multiplication is that a student cannot accept so-so scores across the board. Instead, near-perfect performance in at least two dimensions should become the expected norm for students."

Students still get the benefit of knowing their grade when they submit, and as an added bonus students get more hands-on experience with test-driven development. Having the students write the tests themselves also increases the cost of mutating code until it just works.

The interesting thing is that dd wouldn't even give us an error, but the write speeds were abysmal. Toward the end of the hackathon, we noticed that blocks would be corrupted here and there, while leaving other pieces of data (even entire MP3 files) intact.

I think we ended up pointing to issues with the SD card's bus as the most likely cause for the behavior we saw, but we weren't even certain about this.

we out here!!!