sugar_in_your_tea

joined 2 years ago

DS4 is pretty close.

That depends on how strong each economy is. If both sides have sufficient ability to replace the bots, it could go on for some time.

[–] sugar_in_your_tea@sh.itjust.works 3 points 16 hours ago (2 children)

It'll be like the Cold War, essentially an economic war.

[–] sugar_in_your_tea@sh.itjust.works 2 points 18 hours ago* (last edited 18 hours ago)

Yeah, it's not released or supported outside of the Steam Deck or handheld partners. So you're probably not going to get Nvidia drivers or anything else that's not built in to the kernel.

You don't need it though, you can just run Steam in big picture mode on whatever distro you want.

Yup, looks just like a DualSense controller from the PS5 without the trackpads.

Yup, I love my Steam Deck and usually prefer asymmetric joysticks, so as long as it feels like the SD, it'll be fine.

[–] sugar_in_your_tea@sh.itjust.works 1 points 18 hours ago (2 children)

I'm not sure what the standard for large vs small hands is, but I haven't had issues with pretty much any controller except the OG Xbox controller:

My kids have no issues with either the Xbox 360 controller or DS4 controller that I have.

Steam Box

Ahem, it's a GabeCube.

[–] sugar_in_your_tea@sh.itjust.works 3 points 18 hours ago (2 children)

Yeah, I'm debating getting this one as my first headset. It looks dope.

And even then, most games are available on multiple platforms, for similar prices. So you can get the same game from Steam, GOG, or EGS in many cases, plus all of the stores that sell Steam keys (and Steam probably doesn't get a cut of those sales).

Eh, for the number of CUs, it looks fine. It looks like a slightly smaller RX 7600.

I think that's mostly for the camera. He seems like a really down to earth guy.

 

Current setup:

  • one giant docker compose file
  • Caddy TLS trunking
  • only exposed port is Caddy

I've been trying out podman, and I got a new service running (seafile), and I did it via podman generate kube so I can run it w/ podman kube play. My understanding is that the "podman way" is to use quadlets, which means container, network, etc files managed by systemd, so I tried out podlet podman kube play to generate a systemd-compatible file, but it just spat out a .kube file.

Since I'm just starting out, it wouldn't be a ton of work to convert to separate unit files, or I can continue with the .kube file way. I'm just not sure which to do.

At the end of this process, here's what I'd like in the end:

  • Caddy is the only exposed port - could block w/ firewall, but it would be nice if they worked over a hidden network
  • each service works as its own unit, so I can reuse ports and whatnot - I may move services across devices eventually, and I'd rather not have to remember custom ports and instead use host names
  • automatically update images - shouldn't change the tag, just grab the latest from that tag

Is there a good reason to prefer .kube over .container et al or vice versa? Which is the "preferred" way to do this? Both are documented on the same "quadlet" doc page, which just describes the acceptable formats. I don't think I want kubernetes anytime soon, so the only reason I went that way is because it looked similar to compose.yml and I saw a guide for it, but I'm willing to put in some work to port from that if needed (and the docs for the kube yaml file kinda sucks). I just want a way to ship around a few files so moving a service to a new device is easy. I'll only really have like 3-4 devices (NAS, VPS, and maybe an RPi or two), and I currently only have one (NAS).

Also, is there a customary place to stick stuff like config files? I'm currently using my user's home directory, but that's not great long-term. I'll rarely need to touch these, so I guess I could stick them on my NAS mount (currently /srv/nas/) next to the data (/srv/nas//). But if there's a standard place to stick this, I'd prefer to do that.

Anyway, just looking for an opinionated workflow to follow here. I could keep going with the kube yaml file route, or I could switch to the .container route, I don't mind either way since I'm still early in the process. I'm currently thinking of porting to the .container method to try it out, but I don't know if that's the "right" way or if ".kube` with a yaml config is the "right" way.

 

Apparently US bandwidth was reduced to 1TB for their base plan, though they have 20TB for the same plan in Europe. I don't use much bandwidth right now, but I could need more in the future depending on how I do backups and whatnot.

So I'm shopping around in case I need to make a switch. Here's what I use it for:

  • VPN to get around CGNAT - so all traffic for my internal services goes through it
  • HAProxy - forwards traffic to my various services
  • small test servers - very low requirements, basically just STUN servers
  • low traffic blog

Hard requirements:

  • custom ISO, or at least openSUSE support
  • inexpensive - shooting for ~$5/month, I don't need much
  • decent bandwidth (bare minimum 50mbps, ideally 1gbps+), with high-ish caps - I won't use much data most of the time (handful of GB), but occasionally might use 2-5TB

Nice to have:

  • unmetered/generous bandwidth - would like to run a Tor relay
  • inexpensive storage - need to put my offsite backups somewhere
  • API - I'm a nerd and like automating things :)
  • location near me - I'm in the US, so anywhere in NA works

Not needed:

  • fast processors
  • lots of RAM
  • loose policies around torrenting and processing (no crypto or piracy here)
  • support features, recipes, etc - I can figure stuff out on my own

I'll probably stick with Hetzner for now because:

  • pricing is still fair (transfer is in line with competitors)
  • can probably move my server to Germany w/o major issues for more bandwidth
  • they hit all of the other requirements, nice to haves, and many unneeded features

Anyway, thoughts? The bandwidth change pisses me off, so let me know if there's a better alternative.

view more: next ›