> Microsofts esteemed moat (office) is “Web only” on the lowest tier.
If you've ever used it before, you'd quickly come to the conclusion that web only Office is only useful for someone writing essays for school.
The moment you need to do anything more complex than that, the document renders completely differently on web vs app-- not to mention there are tons of critical features that aren't even available on the web version.
The bigger problem here is it seems like the rust utilities were rushed to be released without extensive testing or security analysis because simply because they are written in rust. And this isn't the first serious flaw because of that.
Doesn't surprise me coming from Canonical though.
At least that's the vibe I'm getting from [1] and definitely [2]
> This code, apart from the source in core/third-party, is licensed under the MIT License, see LICENSE in this repository.
> The English-language models are also released under the MIT License. Models for other languages are released under the Moonshine Community License, which is a non-commercial license.
> The code in core/third-party is licensed according to the terms of the open source projects it originates from, with details in a LICENSE file in each subfolder.
Afaik Anthropic is not giving pretty much any provider model weights, so any inference of Opus is certainly not private. Either going through Anthropic or Bedrock, or Vertex.
Of the three Bedrock is probably the best for trust, but still not private by any means.
Another common tell nowadays is the apostrophe type (’ vs ').
I don't know personally how to even type ’ on my keyboard. According to find in chrome, they are both considered the same character, which is interesting.
I suspect some word processors default to one or the other, but it's becoming all too common in places like Reddit and emails.
> That's the beauty of constraint-based parametric modeling as opposed to, say, modeling in Blender.
I was thinking the same thing. This looks more like an API that makes 3d modeling look closer to CAD, but without realizing that CAD is about constraints, parametrizing, and far more.
Very much so. It feels like it can't have been that common in the original training corpus. Probably more common now given that we are training slop generators with slop.
It doesn't help that the TPM spec is so full of optional features (and the N spec versions), so it's often annoying to find out what the vendor even supports without signing an NDA + some.
TPMs work great when you have a mountain of supporting libraries to abstract them from you. Unfortunately, that's often not the case in the embedded world.
In many industries, once someone has physical access to a device, all bets are off. And when used correctly, TPMs can provide tons of value even when not encrypting the bus.
Which is stupid as those are the vulnerabilities worth determining if they exist.
I can understand in a heavily regulated industry (e.g. Medical) that a company couldn't due to liability give you the go ahead to poke into other user's data in attempt to find a vulnerability, but they could always publish a dummy account detail that can be identified with fake data.
Something like:
It is strictly forbidden to probe arbitrary user data. However, if a vulnerability is suspected to allow access to user data, the user with GUID 'xyzw' is permitted to probe.
Now you might say that won't help. The people who want to follow the rules probably will, and the people who don't want to won't anyways.
The best part is if you consider it a vulnerability, it is one you can't fix.
It reminds me of SQL injection techniques where you have to exfiltrate the data using weird data types. Like encoding all emails as dates or numbers using (semi) complex queries.
If the L(L)M has the data, it can provide it back to you, maybe not verbatim, but certainly can in some format.
Is the idea that you'd have to guess the GUID of a future chat? If so that is impossible in practice. And even if you could, what's the outcome? Get someone to miss a train?
Certainly not "clear" based off what was described in this post.
Your "substance" is "trust Apple will enforce something correctly where there isn't a correct answer". I don't agree with that. Apple has a history of interpreting things favorably for themselves and locking 3rd parties from doing the same things for wave hands reasons.
If you are going to make guidelines, make them evaluable. These aren't. If you care about memory safety, either say use a memory safe language or point to an exact reference guide to use to allow XYZ language to satisfy it.