There are plenty of good resources online. Here are some topics you probably wouldn’t see in an intro algos course (which I’ve actually used in my career). And I highly recommend finding the motivation for each of these in application rather than just learning them abstractly.

• bloom filter
• btree
• b+ tree
• consensus algos (PAXOS, RAFT, VSR, etc)
• error correction codes (Hamming, Reed Solomon, etc)
• garbage collection (mark+sweep, generational, etc)
• generational arena allocator
• lease (i.e. distributed lock)
• log-structured merge trees
• min-cost + max-flow
• request caching and coalescing
• reservoir sampling
• spatial partition (BVH, kd-tree, etc)
• trie
• write-ahead log

It’s almost like Nintendo wanted to make as much money as possible in court.

Don’t most YouTubers make more money with their own sponsorships than from YT ads? Can we start the mass migration to PeerTube already?

Sir, I estimate the project will be completed in 135 days and 11 hours.

couldn’t you always just run a Linux VM at near-native speed, and get the benefits of both?

The obvious downside is that Linux is no longer the host OS. MacOS or Windows would be closed source code managing your hardware. And any VM could only be as fast as the host OS allows it to be.

It’s been this way for at least a decade.

Talos Principle 2. So far I’m enjoying it just as much as the first one.

I love that the EU is cracking down on tech, but I also wish the US government could get in on that awesome rake.

I’m not in the market, but I’ve actually had similar thoughts of building a project on top of NixOS that’s focused on self-hosting for homes and small businesses. I recently deployed my own router/server on a BeeLink mini PC and instead of using something like OpenWRT, I used NixOS, systemd-networkd, nftables, etc.

DM me if you want to discuss more. I think the idea has potential and I might be interested in helping if you can get the business model right (even if it just ends up being some FOSS thing).

Fair, but it’s also limited to the very top of the bell curve at any point in time.

The fastest marathon time for men is 2 hours 1 minute and for women it is 2 hours 14 minutes.

It’s an unacceptable leap in logic to infer (from that statement) anything about populations of men and women. You’ve picked only a single sample from each population and chosen that highly biased representative.

Sorry if this sounds like a conspiracy theory, but how do we know that BlueSky isn’t padding their stats with internal bots? I could see this being a viable strategy to attract users and overcome the social network bootstrapping problem.

How can you tell?

Not exactly. I’m talking specifically about being able to call axum::serve with non-Send futures.

Stop using Brave, people.

I think Kodi is a good choice, but not really sufficient for everything you might want to do IMO.

You could also look into KDE Plasma Bigscreen. It’s still pretty rough around the edges, but I think it aims to do what you want.

I am actually thinking about building something similar with different tech, as I’m not satisfied with any of the existing options. I really want something that’s primarily controlled via a mobile Web interface like the Kore app for Kodi.

I’m not sure what tokio (or axum) can do to avoid the trait bounds. Would it makes sense to provide a “share nothing” runtime implementation that can be injected at startup? I wonder how the intermediate layers (e.g. axum) would indicate that futures are usable by a more generic runtime which may or may not need Send + 'static.

Without some way to write generic code for either runtime, the whole tokio ecosystem would end up bifurcated by this choice of runtime.

Rate-limiting could also be applied at the federation level, but I’m less sure of what the implementation would look like. Requiring filters on a per-account basis might be resource intensive.

Why resort to an expensive decentralized mechanism when we already have a client-server model? We can just implement rate-limiting on the server.

Are sockets not files?