[0]: https://www.duden.de/rechtschreibung/verschlimmbessern

What I've been looking at instead is inference providers that use TEE and E2EE to provide cryptographic guarantees that my prompts and responses are only visible to me and the GPU itself.

Despite their docs and assurances of what their guarantees mean, I'm having trouble getting to a point where I'm actually comfortable trusting them with secrets though. Phala for example seems to be E2EE only to the gateway and will then forward prompts to (potentially third party) providers.

Has anyone been down this path and found a provider they feel safe with?

Files can be purchased by backing the Kickstarter but they won't be sent until November: https://www.kickstarter.com/projects/joelcreates/oddcube-air...

I think this could be substantially cheaper than a build based on a PC case.

You've misunderstood something here. Revolut doesn't "block GrapheneOS actively". I'm running Revolut and most of my banking apps on GrapheneOS right now.

In my experience, there are two major categories of incompatibility:

- High levels of Google Play Integrity checks: app only works on releases of Android that have been allowlisted by Google. The only app that does this for me so far is McDonalds.

- Commercial root detection APIs: some of GrapheneOS' security features like "Secure App Spawning" trip root detection heuristics. This is the kind of incompatibility I usually run into for banking apps. You can disable individual features on a per-app basis these days to get around this.

"[...] We also investigated whether obesity, diabetes, and a healthy diet, all evaluated in 2 categories (no/yes), modified the association between LNCS consumption and cognitive decline by adding a 3-way interaction among the consumption of LNCS, the timescale, and each modifier on model 2."

In the results section: "[...] obesity and diet did not modify the association between LNCS consumption and cognitive decline [...]"

If you want hard numbers, SBB used 1685GWh for passenger trains in 2025 [0].

The bigger problem with this idea is solar in Switzerland. It's fantastic during the summer but close to nonexistent during the winter [1]. Trains need to run year-round, so you'd need to overbuild solar monstrously to power SBB during the winter, or you'd need to solve seasonal electricity storage, which isn't easy. Pumped hydro is great but Switzerland has already built about as many artificial alpine lakes as the population is likely to tolerate.

[0]: https://reporting.sbb.ch/en/sustainability?=&years=5,6,7,1&s...

[1]: https://energiedashboard.admin.ch/strom/produktion

I can download from Usenet at consistently around 10Gbps and I've determined the limiting factor is the combination of client/server behavior and TCP windows. With some customization I've saturated the 25Gbps pipe.

Online games (e.g. League of Legends, Path of Exile) typically have a ping of around 8ms.

25Gbps requires pretty unusual hardware to use (see [0] for example) and you need to pay a couple hundred francs for installation so even among the geeks and nerds, it's not common.

I have it myself but recommend to friends and colleagues to use Init7 but 10Gbps instead.

[0]: https://michael.stapelberg.ch/posts/2021-07-10-linux-25gbit-...

Also, the only ISP that offers 25Gbps is Init7 and they need to have their equipment at the other end of the fiber to offer 25Gbps. I don't think they quite have 100% coverage yet.

Here's how much each energy source contributes to Switzerland's grid: https://energiedashboard.admin.ch/strom/produktion

Right now, solar and other renewables produce enough energy to meet about two thirds of our demand. Solar alone produced around 55GWh of the needed 169GWh yesterday.

Look at new year's day though: consumption was 192GWh (14% higher than yesterday) and yet solar only produced 11.4GWh and that was an unusually good day for winter.

You can't talk about the price of solar, even solar with storage, without talking about the climate it's in. Assuming your prices are for summer or a mild climate like California, you need to multiply those by around 6x to get a system that can replace nuclear for a baseline load in Switzerland.

That brings the price to $180-$510/MWh.

FWIW: I live in Switzerland and have solar panels and a battery on my house. I sell the obscene amount of excess solar I generate in summer to the grid which covers much of the cost I incur buying from the grid in winter. That power is generated by nuclear.

This is surely the first time I'm seeing "on accident" from a journalist. I get that it's used in casual speech but it's never been normal in formal contexts where "proper" use of language is considered important.

To back up my words with evidence, take a look at [0]. If you look at some of the examples from the late 90s [1] you'll see that most of the uses of "on accident" that did exist weren't even used in the "accidentally" sense but in contexts like "on accident compensation" or "on accident rates" - to introduce a topic. To eliminate that, we can do something like [2] and see that this modern construction basically didn't exist until 2010.

If you play with the corpus, you can see that it's not really used in English English, only American English.

[0]: https://books.google.com/ngrams/graph?content=on+accident%2C...

[1]: https://www.google.com/search?q=%22on%20accident%22&tbm=bks&...

[2]: https://books.google.com/ngrams/graph?content=it+accidentall...

The problem is due to the quartz oscillators these devices use, which are the same ones we use in phones, computers etc., which have the same problem as a result.

You don't notice this because just about every network-connected device these days uses NTP or something similar to keep its clock constantly up to date, but the clock itself is still inherently inaccurate.

There are also other mechanisms to keep clocks in sync by the way. Some mains-connected devices keep time using the 50Hz/60Hz mains voltage. Various countries have radio broadcasts that devices can be used to keep time (DE, US and JP run them, I believe).

Even if you want a NIC with a stable oscillator or GPS inputs to act as a grandmaster, you can buy an E810 with the necessary hardware from eBay etc. for a few hundred or DIY something yourself much cheaper.

All of the copy seems to be built around Solana, "Web3" and crypto. It doesn't seem to have any appeal outside of that. It's not clear what the software even is. The docs [0] seem to indicate it's just Android, with some SDKs for interacting with the "Web3" stuff.

This isn't a "serious attempt at creating an app store that can compete with apple or google", it's just another "Web3" project. It's exciting to people within that ecosystem and utterly uninteresting to anybody who isn't.

0: https://docs.solanamobile.com/get-started/development-setup

I think the answer is somewhat the same as where we've gone with many HTTP servers: proof of work. Just like Captcha and more recently Cloudflare turnstile required you complete a task before you'd be able to access as website, senders should be required to complete a task before you'll accept their email.

It can even be a sliding scale: the higher you want the chances of the recipient seeing it to be, the more work you need to do.

However this also break emails considered "legitimate" by businesses, like marketing newsletters and other nonsense, which is why it'll likely never happen.