DenseComet

I believe you can set a different proxy on a per container basis, so you could for example have a VPN container and a work container that send traffic via different places.

Yep. The hardest part of a k8s cluster at home is ingress and storage. Previously I was using metallb and port forwarding, which worked ok, but not very reliably for various reasons. A cloudflare tunnel sidecar completely solved the ingress issues.

Nomad is pretty great for a lot of things, especially self hosted. The only reason I prefer k8s is the ecosystem. Even though there are standardized specs like CSI, they were written with k8s in mind, so some drivers are completely broken on Nomad. Also, most cloud providers offer managed k8s, but very few offer managed Nomad.

This is the explanation a Plex employee gave for the lack of personal media showing up in their Apple TV integration.

> This feature will only work with our free on demand movies and TV shows. We’d love to integrate personal media as well but that’s not technically possible for a couple reasons. To make this work we provide Apple with a list of content we have available for streaming. As detailed in our privacy policy, we don’t know what content our users have in their personal media libraries.

https://www.reddit.com/r/PleX/comments/lniiij/plex_testing_t...

I should've phrased it as all in on Next really. I really like Vercel and Next.js serverless for hosting, and I've usually put APIs on a subdomain. The issue is that then using Blitz for authentication and rpc layer becomes very hard to do.

Next pushes towards serverless functions and API routes that I didn't really enjoy using for more than just a trivial endpoint. Blitz is currently built on top of Next so this same issue came up, and its value proposition is really only there if you use Next.

I'm looking forward to this change and using Blitz again, as the frontend experience was super nice.

Similarly to Bitcoin, miners are paid by a combination of minting HNT (which halves over time) and fees paid by network usage. I'm very curious to see how this will play out over time. If network usage / fees don't increase over time while HNT issuance drops, will miners stop mining? Would the revenue still be enough to incentivize long term maintenance? Unlike Bitcoin, if miners stop mining, that directly reduces the value of the network due to a decrease in coverage. Is there a possibility of a spiral, where network usage drops due to reduced network coverage, and then miners stop mining due to the drop in usage?

I've not really dug into the details as to what solutions Helium has, but it is quite interesting to see how this experiment will play out.

It's not super clear, but it looks like Fermyon was started by people formerly at DeisLabs, which has done quite a bit of wasm work. It looks quite promising, even more so considering the lineage and expertise of the team.

Take a look at ScyllaDB Alternator [1], which is API compatible with DynamoDB. Scylla also supports multiregion clusters, which should help with latency. I've not used alternator, but I've had a good experience with Scylla, and it might be worth looking into as a lower effort way to move off DynamoDB.

[1] https://www.scylladb.com/alternator/

This seems like a no go for anything where the dataset used for training includes any private data at all, or even public images that have been privately labeled by the company. It makes sense for hobbyists, but I doubt this entire platform was created for only hobbyist use in mind.

They say they intend to implement encrypted hosting environments in the future, but considering the number of security exploits that Intel SGX and its equivalents have had, I'm not sure I'd trust that either.

No harm in staying with YouTube for now, as long as you have a local copy of all your videos.

That reminds me of this article[1] by Bryan Cantrill. One takeaway is that Rust's ability to easily import generic data structures makes the average Rust program faster than the average C program.

With a bit of effort, C can be made faster than Rust, but if I'm writing a simple utility in C that needs a linked list, I'm going to write the simplest possible implementation, straight from an algorithms textbook. It's better for it to be slower, but more understandable and maintainable.

With Rust, the implementation I import has far more work put into it. I don't need to worry about how complex it is though, since its part of the standard library and I trust that people smarter than me have checked over what it does.

[1] http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

It feels like the solution to most of this is static typing, not writing a ton of tests by hand for every single dependency. Observable changes in a dependency's logic should be caught by your own unit tests. Changes in dependency function names or signatures should be caught by the compiler.

Stock Tokio is tuned towards the general set of applications, attempting to make things work well out of the box, while being ergonomic to use. But, this isn't set in stone. There are knobs and patterns that can be used to really squeeze out performance, as seen with Actix Web, which is based on Tokio [1].

[1] https://www.techempower.com/benchmarks/

A big reason seemed to be compatibility with the RocksDB on-disk file format.

https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/

Backblaze also supports that pricing model with B2, which is a fixed cost per gigabyte stored per month. B2 also has an S3 compatible API, which lets you use any backup software you want.

Cloudflare also recently published a bunch of posts about their transition to post-quantum cryptography. Is it that NIST is close to standardization and organizations are starting to experiment, or is it something else?

Looking at this docs page[1], it doesn't look like the execution environment gets reset completely between each request. Do you partition free/paying users or public/private repos? It seems like an attacker could gain a foothold for longer than just their request with malicious code.

[1] https://docs.aws.amazon.com/lambda/latest/dg/runtimes-contex...

Yeah I never understood the decryption issue either. Even if you don't use them, Cloudflare offers a lot of services that do need to understand what the payload is. Its like complaining an AWS ELB needs to decrypt traffic to load balance.

Install a private CA and just decrypt TLS.

Applications trust /dev/urandom to be secure. If your scenario ends up being true, then instead of /dev/random acting like /dev/urandom, /dev/urandom should act like /dev/random since it is supposed to be secure, and we're back to having no distinction between the devices.

Can you really still call what Expensify uses SQLite? It is very heavily based on SQLite, but they say that they've "wrapped it in a custom distributed transaction layer named Bedrock". Feels like they've gotten much closer to a traditional DB architecture, with the related management overhead that people try to avoid by using SQLite.

http://www.bedrockdb.com/

It's not obvious (unless you follow the author on twitter[1]) but a large portion of this has been rewritten with new content. Among other things, it now includes a section on detecting undefined behavior in unsafe blocks using Miri[2], which is incredibly neat.

[1] https://twitter.com/Gankra_/status/1486928208528293888 [2] https://github.com/rust-lang/miri

I've done this with Nixos. Bash and most other tools are too brittle to get the system back to the same exact state.

Yep. I use Firefox when my laptop is docked and Safari the rest of the time. It might not matter for the M1 laptops, but with Intel, the difference in battery life is extremely noticeable.

What in the world is your threat model? You need some concept of sessions somewhere, even if it's just a list of which client certs (aka sessions) are valid in case someone looses a yubikey. Those certs should also be short lived, since they don't live in the yubikey itself. And a TLS client cert absolutely adds more than just a nonce.

Instead of generating client certs client side, generate a elliptical curve key pair who's public key you sign with the yubikey and send to the server. Then, sign every request with that key and the server can verify it using the public key sent previously. All that can be done in js, without a jwt or sending anything other than a request and signature. It's essentially a client cert.

I still don't really understand how much more security it'd get you than bog standard webauthn, especially considering it'd be a custom, less tested system, but you can already do something similar to your idea using standard cryptographic primatives.

You may be able to go the Webauthn route instead. It won't completely eliminate sessions, but you could instead sign short lived JWTs. The main benefits would be the ability to use any compatible device (ios and andriod natively support it backed by a secure enclave) and the ability to attest that the authenticating device is from a trusted manufacturer, such as Yubico, Apple, Google, etc. I'm not sure if it's possible to sign a request without user input, but if so, you could include a signature with every request.

Heh. I get why you're using Discord, but it's unfortunate that a project building on Matrix does not use it for chat.

Isn't that a function of being an EV rather than an ICE? I'd expect an EV from any of the traditional automakers to also require comparatively little maintenance.

I literally own my lastname as a Handshake TLD. I got it way back in September 2020, when they were still slowly releasing them. I love the idea of using first.lastname. It's great branding. However, my personal benchmark is can I hand a random person a business card and expect them to be able to visit my site. The answer to that right now is very clearly no and so it sits unused.

Adoption by default is a huge deal and you can't ignore it by saying that something "can" use it if you configure your router properly or this and that. The vast majority of people will never change it. Re. Firefox, I just tried switching it to NextDNS, but it seems like the default NextDNS resolver does not resolve Handshake domains.

Putting aside all the issues with DANE as a replacement to HTTPS, no browser supports it. This is why I don't use my handshake TLD for my personal/internal sites either.

Look, actual Handshake adoption would benefit me quite a bit, since I own a great TLD. I will keep an eye on adoption, but its very clearly a long road, and the project itself has a number of issues besides just adoption. It's cool, but you have to be realistic.