sugar_in_your_tea

joined 2 years ago
sorted by: new top controversial old
Valve confirms Steam Machine will be priced ‘like a PC with the same level of performance’ in c/games@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 1 points 12 minutes ago

Yeah, I've been guessing $800-1000. That's a decent deal on a prebuilt with this performance.

Valve confirms Steam Machine will be priced ‘like a PC with the same level of performance’ in c/games@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 2 points 16 minutes ago (1 children)

I used Linux for regular desktop stuff before I installed Steam on it. Steam got me back into gaming.

Microsoft finally admits almost all major Windows 11 core features are broken in c/technology@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 10 points 1 day ago

Nah, if there's one thing they thoroughly test, it's the spying.

How One Uncaught Rust Exception Took Out Cloudflare in c/technology@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 10 points 1 day ago

Ift is precious and beyond compare. It has tools that most other languages lack to prove certain classes of bugs are impossible.

You can still introduce bugs, especially when you use certain features that "standard" linter (clippy) catches by default and no team would silence globally. .unwrap() is very controversial in Rust and should never be used without clear justification in production code. Even in my pet projects, it's the first thing I clear out once basic functionality is there.

This issue should've been caught at three separate stages:

  1. git pre-commit or pre-push should run the linter on the devs machine
  2. Static analysis checks should catch this both before getting reviews and when deploying the change
  3. Human code review

The fact that it made it past all three makes me very concerned about how they do development over there. We're a much smaller company and we're not even a software company (software dev is <1% of the total company), and we do this. We don't even use Rust, we're a Python shop, yet we have robust static analysis for every change. It's standard, and any company doing anything more than a small in-house tool used by 3 people should have these standards in place.

It's on the bucket list in c/whitepeopletwitter@sh.itjust.works
arc raiders on Linux? in c/linux_gaming@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago

It's Steam Deck verified, no need to check ProtonDB.

Are you being ripped off? Good luck! in c/whitepeopletwitter@sh.itjust.works
[–] sugar_in_your_tea@sh.itjust.works 1 points 1 day ago (1 children)

Yeah, TP is renewable by design, since it comes from trees. Being from a grass like bamboo doesn't change that, and bamboo isn't absorbent, so I'm very concerned about the process they're using to produce something that's supposed to be somewhat absorbent.

Are you being ripped off? Good luck! in c/whitepeopletwitter@sh.itjust.works
[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago

I wanna know how many square cubits it is.

Bracing for impact in c/selfhosted@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago (1 children)

Use something like Backblaze or Hetzner storage boxes for off-site backups. There are a number of tools for making this painless, so pick your favorite. If you have the means, I recommend doing a disaster recovery scenario every so often (i.e. disconnect existing drives, reinstall the OS, and load everything from remote backup).

Generally speaking, follow the 3-2-1 rule:

  • 3 copies of everything on
  • 2 different types of media with
  • 1 copy off site (at least)

For your situation, this could be:

  • 3 copies - your computer (NVMe?), TrueNas (HDD?), off-site backup; ideally have a third local device (second computer?)
  • 2 media - NVMe and HDD
  • 1 copy off site - Backblaze, Hetzner, etc

You could rent a cloud server, but it'll be a lot more expensive vs just renting storage.

Valve put up a new Steam Linux Runtime 4.0 with a move towards 64-bit in c/linux_gaming@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago* (last edited 1 day ago) (1 children)

Glad you got it fixed. 🙂

Almost every reply is also explaining what the runtime is.

I boosted it up a bit for other people who come along w/ a similar concern. You seemed mistaken at first until a few threads deep, so there's likely someone else who is just as, if not more, confused.

Valve put up a new Steam Linux Runtime 4.0 with a move towards 64-bit in c/linux_gaming@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 3 points 2 days ago (3 children)

Usually when steam refuses to launch, it's because there's some Steam process that's borked but still running. Most of the time, a simple pkill steam fixes it (yes, that includes for flstpak`).

As mentioned down thread, the runtime isn't your problem. The runtime is what's needed for native Linux games and I think is also used by proton (not used by Steam itself), so it's kind of like proton for native games. Steam doesn't use the runtime at all to launch.

If killing Steam doesn't work, try rebooting. If that doesn't work, try updating the flatpak. If that doesn't work, I suppose reinstall Steam.

Valve put up a new Steam Linux Runtime 4.0 with a move towards 64-bit in c/linux_gaming@lemmy.world
[–] sugar_in_your_tea@sh.itjust.works 1 points 2 days ago* (last edited 1 day ago) (1 children)

Usually it's because Steam is still running in the background, so a simple pkill steam should close all the processes and allow it to launch. No need to reboot.

14
Question about quadlets and kube play (sh.itjust.works)
 

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.

3
Hetzner announces price hike for cloud servers and bandwidth cut of up to 95% (gigazine.net)
submitted 9 months ago* (last edited 9 months ago) by sugar_in_your_tea@sh.itjust.works to c/selfhosted@lemmy.world
3 comments fedilink
 

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.

1
Looking for HW recommendations for DIY NAS/Homelab (sh.itjust.works)
 

Here's what I currently have:

  • Ryzen 1700 w/ 16GB RAM
  • GTX 750 ti
  • 1x SATA SSD - 120GB, currently use <50GB
  • 2x 8TB SATA HDD
  • runs openSUSE Leap, considering switch to microOS

And main services I run (total disk usage for OS+services - data is :

  • NextCloud - possibly switch to ownCloud infinite scale
  • Jellyfin - transcoding is nice to have, but not required
  • samba
  • various small services (Unifi Controller, vaultwarden, etc)

And services I plan to run:

  • CI/CD for Rust projects - infrequent builds
  • HomeAssistant
  • maybe speech to text? I'm looking to build an Alexa replacement
  • Minecraft server - small scale, only like 2-3 players, very few mods

HW wishlist:

  • 16GB RAM - 8GB may be a little low longer term
  • 4x SATA - may add 2 more HDDs
  • m.2 - replace my SATA SSD; ideally 2x for RAID, but I can do backups; performance isn't the concern here (1x sata + PCIe would work)
  • dual NIC - not required, but would simplify router config for private network; could use USB to Eth dongle, this is just for security cameras and whatnot
  • very small - mini-ITX at the largest; I want to shove this under my bed
  • very quiet
  • very low power - my Ryzen 1700 is overkill, this is mostly for the "quiet" req, but also paying less is nice

I've heard good things about N100 devices, but I haven't seen anything w/ 4x SATA or an accessible PCIe for a SATA adapter.

The closest I've seen is a ZimaBlade, but I'm worried about:

  • performance, especially as a CI server
  • power supply - why couldn't they just do regular USB-C?
  • access to extra USB ports - its hidden in the case

I don't need x86 for anything, ARM would be fine, but I'm having trouble finding anything with >8GB RAM and SATA/PCIe options are a bit... limited.

Anyway, thoughts?

view more: next ›