sugar_in_your_tea

joined 2 years ago

The modularization was good.

The modularization was a security nightmare. These plugins needed elevated privileges, a d they all needed to handle security themselves, and as I hope you are aware, Flash was atrocious with security.

Having a single "plugin" system means you only need to keep that one system secure. That's hard enough as it is, but it's at least tractible. And modern browsers have done a pretty good job securing the javascript sandbox.

That was better back then, people had realistic expectations

I don't think that's true. I think there just weren't as many attacks because there weren't as many internet users. Yet I also remember getting viruses all the time (at least once/year) because of some vulnerability or another, and that's with being careful.

You should take off those rose colored glasses.

I appreciate that people not knowing as much about security is problematic, but that's because the average person is far more secure than they were even 10 years ago. Getting a virus is pretty rare these days, Microsoft has really stepped up their game with Wndows and browsers have as well. I haven't worried about getting a virus for many years now, and that's thanks to the proactive security work in sandboxing and whatnot that limits exploits.

A lot of the scams and whatnot these days either attack outdated systems (esp. insecure routers running default creds) or merely use social engineering because you can't simply use an off-the-shelf flash exploit or something to get privilege escalation to install your malware. Attacks certainly exist, but they're far less common than they were 10-20 years ago as people started being online constantly.

those plugins being disabled by default

Yes, I am annoyed at JavaScript being enabled constantly and not having fine-grained control over specific permissions (mostly just location, mic, camera, and storage).

Unfortunately, that ship has sailed. But I still very much prefer the modern "everything uses JavaScript" to the old insecure Flash and Java applets.

Doesn't mean your eyeballs don't have value.

If you're going that far, you've taken a wrong turn somewhere. Please ask for help before digging into compiling stuff, unless that's what you're into, there's probably a simpler solution.

Yeah, there really aren't any good contactless alternatives to Google, Apple, and Samsung.

My current setup is reasonably good, I have a Google Watch (WiFi only) that only connects at home, and I only use the Google Watch app on a separate Android profile. The Wallet app refreshes payment tokens, and I don't need any Google spyware running for regular purchases.

I'm hoping some cryptocurrency or something will get widespread enough so I can have FOSS contactless payments. I don't think the traditional finance industry will ever support FOSS payments.

I had a class that "required" Windows, I did just fine with Linux. YMMV.

Millions of 2 passenger trucks that can barely tow an empty trailer? This isn't something your average "truck enthusiast" will want, this only really appeals to people who will actually use it.

Yeah, an IP range totally works. Figure out the subnet info and add that to a whitelist. It's a pain, but it should keep the script kiddies at bay.

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

It saves the comment/post, and you can find them later by going to your profile.

Here it is in the mobile version of the web app, it's the star. Click that, and then you'll see then under your profile -> saved.

Yeah, that's disappointing, and the maximum payload/tow capacity significantly under a ton is also a bummer. I may still need to rent a truck if I get this, but it could handle a lot of my local hauling needs.

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

What's wrong with an EV pickup? Pickups are incredibly useful, and if it's an EV, it could also be a commuter. I don't need a truck very often, so I tend to rent when I need one, because they're so terrible on fuel. But if it's an EV, there's a chance it's reasonably efficient, so I could use it as my commuter and occasional dump/furniture store/hardware store/nursury run vehicle.

This isn't going to attract those dudes who like to lift their trucks and piss off everyone on the road, this is too small for those egos. This is going to appeal to people who need a truck for local use, like small business owners and DIY types.

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

Have you tried the "star" feature? That does exactly what you're looking for, but without useless posts.

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

I have my smart TV access it over my local network. If you're using a friend's instance, you could set up a WiFi SSID that tunnels everything over your VPN.

If that's onerous, you can make it publicly accessible, but only for whitelisted client IPs.

 

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 ›