ibotty

Hayden Kennedy said that on the enormocast.

Yes. Caveat: It might not really be worth it if all your infrastructure is managed by these newfangled infrastructure-as-code-things that are quick to roll out (OpenShift/OKD, Talos, etc.) and you have only one repo to change SSH keys (single cluster or single repo for all clusters).

There are some serious security benefits for larger organizations but it does not sound as if you are part of one.

Beer, cider and bread (leavened with yeast or sourdough at least) are fermented. What was your point again?

The problem is the device attestation. See https://grapheneos.org/articles/attestation-compatibility-gu... for details.

Well, double standard is of course a thing (like accusing the only democracy for not being democratic enough without saying anything about much more oppressive regimes around; but also about surveillance in one place and also another). I think it is to make a different point though.

This funding from the US was to get around surveillance (everywhere), so it makes sense to argue, that a rival global player exports surveillance tech, because the funded tech is to counter that. That argument would not work with Israeli surveillance tech.

As if the guardian was overly pro-Israeli. I would argue that it makes more sense in that context to mention Chinese surveillance tech, because it's not an ally of the US.

Really important to first, pick that example of content moderation and then point out that he's an Israeli. Maybe think about why you used that example when there are countless others regarding free speech/internet freedom.

Very unhelpful comment. Some people don't want to run on anything AOSP. Being able to manage the device with standard linux tooling is a major plus for some people.

I don't think your run often into these things, because of Rust's ownership enforcement. But I might be misunderstanding you, because it's all pretty abstract and I might not have the whole context.

There is relatively little Rust in the kernel, but there are even less Rust CVEs. In this cycle alone there were 160 CVEs, one in Rust. The first one! The amount of rust is way less than 1/160 and even that statistic is off, because one should count all CVEs.

https://gitlab.redox-os.org/redox-os/ion/-/blob/master/examp...

But I assume it's for redox, so you can't use it on a regular linux.

Or use decap https://decapcms.org/

Can you use mobilepay? (Or is that not a thing in Sweden?)

One problem is that you can't filter its "syscalls" as you can regular syscalls. This removes a security boundary that e.g. container runtimes regularly use. So you cannot use it in your regular kubernetes cluster without weakening its security for these pods.

What's the joke exactly? English is not my native language.

The numeronym a11y has been around for at least 15 years now.

Not a maintainer. A disgruntled developer. And one with questionable patches. Please read the gitlab discussions before coming to this conclusion.

Well-known as in notorious, right?

I am pretty sure you are wrong. They even tell in the README https://github.com/X11Libre/xserver that nvidia is going to be a problem.

FWIW signal opts-out of recall. There is a blog post about it.

And if there were one (`drop` kind-of is that function though), it will consume the file handle so you cannot call it again.

That difference is still pronounced, yes. But the workload is so different. Training AI is hardly random read. Still not a comparison which should lead you to any conclusions.

Look at the hardware first:

The hardware in the Ceph test is only capable of max 1.7TiB/s traffic (optimally without any overhead whatsoever).

I also assume that the batch size (block size) is different enough that this alone would make a big difference.

The comparison is a little pears to apple. Similar nutritions but different enough to not draw conclusions. The hardware in the Ceph test is only capable of max 1.7TiB/s traffic (optimally without any overhead whatsoever).

I also assume that the batch size (block size) is different enough that this alone would make a big difference.

Can you point out where it says it won't be a reproducible output?

https://github.com/signalapp/Signal-Android/blob/main/reprod...

https://old.reddit.com/r/rust/comments/1ish5vd/eserde_dont_s...

It's not only potentially infested with vulnerabilities. It's also not possible to filter io_uring using seccomp at all. So if you allow io_uring, you allow all that is possible with it.

I bought a 1st generation framework in a pretty early batch. In between I upgraded to a ryzen mainboard and use the old mainboard as a desktop computer in the dedicated case.

The old battery is not as good as it were (even though I only charge it until 75%, which the bios lets me configure) and the display hinges are a little too weak. The hinges got fixed for newer models, even in the factory second 1st gen Intel I bought for a friend they are fixed.

There was a time when they could not keep up with bios updates, but that has apparently been sorted out. And it's not worse than other vendors...

I have no regrets.

IMO the big problem is that it's very hard (and AFAIK no way has even be proposed) to restrict from the outside which syscall-alikes are allowed via io_uring. This is trivial with regular syscalls. That's important if you ever co-host applications with different security domains.

Is there some documentation on how to integrate it into a different web app? I would really like to open a template that is stored in the database and handle sending the mail, "exporting" (rename it to "save"), etc.

Is that possible?