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.

Doesn't surprise me coming from Canonical though.

At least that's the vibe I'm getting from [1] and definitely [2]

[1] https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys... [2] https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...

> 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.

Of the three Bedrock is probably the best for trust, but still not private by any means.

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.

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.

What about SFT?

Presumably basing this of Qwen is the reason it can be done for so cheap?

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.

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.

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.

Certainly not "clear" based off what was described in this post.

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.

This is meaningless. Apple can carve out special exceptions for themselves all day long.