When talking about media streaming, there’s a number of other things that cause problems Bandwidth, meaning the total amount of information you can send overall, is less likely to be a problem versus jitter, packet loss, and latency spikes.

For this purpose, but OP would tune both the server and the clients to cache ahead more, or send in smaller packets, it could possibly be a good workaround.

Spending an insane amount of money putting what I’m guessing is illegally obtained content on a CDN distribution is crazypants.

Bandwidth does not degrade over distance. That’s not how that works…

Again, I’m confused on what you’re suggesting the actual issue is here.

Uplink is exactly the problem. Not sure why you think otherwise. The internet doesn’t work by multicast.

You’re describing a CDN. You can’t afford it.

I’d look more into boosting whatever your uplink is versus trying to distribute to localized users.

Mkay. So you’re just some person out here on the Internet who has zero concept of how this works as well I’m assuming?

Feel free to dispute any single point I’ve made.

Well, let me break it down for you since you don’t seem to work in this space:

1. A Roadmap is a strategic timeline of targeted goals that are estimated to be completed in a specific timeframe that is NOT nebulous. It’s done this way to provide consumers of a product some knowledge of where the product is going to entice them to buy-in to said product to allow them to estimate their own commitments to the project and adoption.

2. A backlog is NOT a Roadmap. I planned orchestration of tickets is a Roadmap. We create this to ensure users that problems they are experiencing will be resolved, and in what order to expect them to be resolved. This works for both for-profit engineering, and also FOSS projects. A great example of this is the Roadmaps provided by distros uses by Enterprise customers.

3. Your comment about “inflexible commitment” seems to say you don’t understand the above points. If you’re pushing a product which you want people to adopt, and you’re communicating to them why they should adopt it, the last thing you would want to do is say “Hey, we’re kiiiiinda going this way, but maybe not. We’ll see.”

4. Programming DOES work like an assembly in a sense. That’s why you have tickets, tags, classification, triage, status, and…backlog. What gets thrown in the floor is what I’m talking about.

Regardless of how you feel about the pace of the project, it’s absurd to throw out a bunch of ideas as tickets and expect them to all get done without a commitment. Or, dare I say, a roadmap.

Helm sucks. You don’t even need it for what you’re trying to do.

Mint is for desktops. Hands down.

Run something paired down for servers. Fedora Server, or plain Debian are fine. CoreOS or Talos if you’re trying out some k8s stuff.

Yes, it’s mostly just package selection, but you don’t need to sift through the cruft and clean up all the desktop shit running you don’t need.

It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap. 75% of Open tickets will never get resolved anyway.

Poor cow just wanted to escape and have a nice swim. Buncha dicks decided to fuck with her instead.

Docs say you can choose what to sync, and disable syncing entirely where you don’t want it: https://docs.nextcloud.com/server/latest/user_manual/en/desktop/usage.html

Pretty sure you should have the ability to choose what to sync, either from the server, or the client. Seems kind of dumb for it to automatically assume you have the space on the client device to sync EVERYTHING.

Just use an e2e encrypted mail provider instead.

This one. Watched it like 5 times. Hilarious every single time.

Wha??? A Microsoft product!!! Nooooo… c’mon

Well, firstly, it’s not what Tailscale is meant for. I’m getting downvoted by the people using the wrong tool for the wrong job.

You don’t install a VPN on all your local machines just to talk to each other. That’s insane. You especially don’t install one that, while misconfigured, is sending all of its traffic OUTSIDE of your local network, then back in. This is what Tailscale on a number of local machines will do by default.

The way Tailscale works is by installing a Wireguard client on a machine. It then checks in with their DERP servers to figure out it’s network situation (behind NAT, peers in the network, routing tables…etc). So when you have more than one client on the Tailscale network, it automagically assumes some things, the first being that these two machines dont have a more direct route to talk to each other.

So then it will attempt to bridge a path between the DERP server each client is checked into, and pass traffic that way. Which means you then have two machines on the same local network sending traffic OUTSIDE of that network, then back in to complete a VPN network.

This is stupid.

You setup multiple different networks and use exit nodes to bridge two networks together with Tailscale. That’s the entire point. This means setting up routes to let the orchestration layer know that a set of certain machines exist in the same network, and shouldn’t use Tailscale to communicate with each other. Then it will only be using routes for REMOTE networks, where other clients exist, to pass traffic over the Tailscale network.

May I ask what you were planning on doing with Tailscale? I can point you in the right direction.

https://gist.github.com/camullen/0c41d989ac2ad7a89e75eb3be0f8fb16

Just cut Windows out as much as possible and run everything in WSL. Setup everything to boot straight to all your WSL layers, and aside from the absolute shit Base OS, it should be the same.

Move your Nginx pets to something else. Pretty simple.

Okay, but give a little look into where your disk is using space.

du -hsc /

And work from there.

It depends on where that storage was used. Some details would be useful.

At its core, you shouldn’t need to keep any previous layers than the one you’re using for the OS.

You also technically don’t need snapshots for anything but your personal file space.