sugar_in_your_tea

joined 2 years ago
[–] sugar_in_your_tea@sh.itjust.works 43 points 2 months ago (2 children)

If an AI can effectively do your coursework, why wouldn't AI replace you in the industry?

It all depends on what you're looking for. I've put hundreds of hours into games and gotten way less than $1/hr, and I've also had a great experience paying significantly more.

So I don't see games in terms of $/hr, especially these days when I'm more limited by time than money. Instead, I look for unique experiences with cost being a much lower factor. Generally speaking, I spend much less than $1/hr since I buy a lot of older games, but I've spent far more ($5-10/hr) on particularly interesting games.

But yeah, generally speaking, I'm willing to pay more for indies than AAA titles because indie games are more likely to offer that unique experience.

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

As a manager of sorts, I already know if people are doing their job: the work gets done. I'm involved enough to know how much time their work should take and see through their BS since I do similar work.

Maybe these bosses should do the same: do similar work and you'll know when they're BS-ing you.

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

Why? Look at how many people here say they want Steam OS, and Lemmy skews heavy toward Linux users. This is that, but OOTB.

I don't think it'll sell anywhere near as well as the Steam Deck, but it's also a less exciting form factor. I do think it'll sell a fair number of units though.

The cheapest equivalent prebuilt I can find with similar specs (RX 7600 is slightly better than the Steam Machine) is $850, and a DIY build is more like $900 (lots of corners cut), so there's probably not much margin on the prebuilt. Valve is probably saving some cash with their custom CPU, and they're probably shipping it with a Steam Controller, hence the $800 target. If component prices rise significantly before launch, I could see $1k.

  1. Yeah, I'm guessing $800-1000, and they'll probably throw in a Steam Controller. That's about how much a comparable PC would cost
  2. I've been debating it, but it needs to be something my 5yo can use.
  3. And that's Valve's target market here, those unwilling to DIY.
[–] sugar_in_your_tea@sh.itjust.works 11 points 2 months ago (8 children)

Get ready to riot because there's no way it's that cheap. My money is on $800-1000.

That's a rip off, it'll be more like 1/4 troy ounce, if that

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

Eh, I don't particularly enjoy building PCs, but I do it because it's cheaper, esp. for upgrades. I'm really not the target market for this.

That said, this is the right product for a lot of people. Many don't want to mess with their gaming system, they want it to just work. That's why consoles are popular, and the Steam Machine being a bit more expensive than a console and get access to Steam's catalog is very attractive to a lot of people, especially if it otherwise works like a console.

I see you ignored my entire comment.

No, I responded to the relevant part. I was using segfault as a metaphor, not arguing that it's actually the same mechanism underneath. If you're getting panics in production code, I consider that just as much of an emergency to fix as a segfault, and Rust helpfully gives you stack trace info with it. It's not the same idea as an exception, which could signify an unrecoverable error or an expected issue that can be recovered from.

I don’t know what is more explicit about expect

It forces you to write a message, so most temporary uses will be unwrap(). I use unwrap() all the time when prototyping for the happy path, and then do proper error handling later. This is especially true in larger projects where I can't just throw in anyhow or something and actually need to map error types and whatnot. I don't use expect() much (current hobby project has 4 uses, 3 for startup issues and 1 for hopefully impossible condition) but I think it makes sense when there's no way to continue.

But yes, unwrap() is perhaps the first thing I look for as a reviewer, which is why it's so surprising that this is the issue. At the very least, it should have been something like expect("exceeds max file size"). I personally prefer explicit panics in production code, but expect is close enough that it's personal preference.

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

[–] sugar_in_your_tea@sh.itjust.works 4 points 3 months ago (1 children)

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

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

Yes, it's not the same since you get a stacktrace (if enabled) and a message, but it's the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it's almost as unhandleble.

Basically, you don't want a panic to crash your program in most cases. If you do, make it explicit (i.e. with expect()). unwrap() tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there's an explanation (or it's obvious from context) otherwise.

 

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.

 

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 ›