ramielrowe @ ramielrowe @lemmy.world

Posts

0

Comments

45

Joined

2 yr. ago

I'd take a look at packer and ansible. Packer can be used to prepare a new base image for your VMs. And ansible can be used to automate the provisioning of a VM once it's booted.

Slightly educated guess. True organic cork is produced by cutting the bark off specific trees. There are limited climates it grows. I would guess the scale with which we produce bottled drinks would require significantly more trees and labor that we currently have. And thus cork prices would skyrocket.

If you're considering video transcoding, I'd give Intel a look. Quicksync is pretty well supported across all of the media platforms. I do think Jellyfin is on a much more modern ffmpeg than Plex, and it actually supports AMD. But, I don't have any experience with that... Only Nvidia and Intel. You really don't need a powerful CPU either. I've got my Plex server on a little i5 NUC, and it can do 4k transcodes no problem.

You really don't need an AIO with a 5600X. Just grab a reasonably sized tower cooler and call it a day. There's less to fail, and less risk of water damage if it fails catastrophically. I've found thermalright to be exceptionally good for how well priced they are. Not as quiet as Noctua, but damn near the same cooling performance.

Another thing to consider is that a 5600X doesn't have built in graphics. I think you'd need to jump up to AM5/7600X for that.

A coworker of mine built an LLM powered FUSE filesystem as a very tongue-in-check response to the concept of letting AI do everything. It let the LLM generate responses to listing files in directories and reading contents of the files.

Honestly, I don't mind them adding ads. They've got a business to support. But, calling them "quests" and treating them as "rewards" for their users is just so tone-deaf and disingenuous. Likewise, if I've boosted even a single server, I shouldn't see this crap anywhere, let alone on the server I've boosted.

After repeated failures to pass a test, I do not think it is unreasonable for the business to stop paying for your attempts at a certification. Either directly via training sessions and testing fees, or indirectly via your working hours.

In the US, salaried engineers are exempt from overtime pay regulations. He is telling them to work 20 extra hours, with no extra pay.

Commentary from someone quite trusted in the historical gun community and who's actually shot multiple Welrods/VP9s: https://www.youtube.com/shorts/POubd0SoCQ8

It's not a VP9. Even at the very start of the video, on the first shot before the shooter even manually cycles the gun, gas is ejected backwards out of the action rather than forward out of the suppressor.

In general, on bare-metal, I mount below /mnt. For a long time, I just mounted in from pre-setup host mounts. But, I use Kubernetes, and you can directly specify a NFS mount. So, I eventually migrated everything to that as I made other updates. I don't think it's horrible to mount from the host, but if docker-compose supports directly defining an NFS volume, that's one less thing to set up if you need to re-provision your docker host.

(quick edit) I don't think docker compose reads and re-reads compose files. They're read when you invoke docker compose but that's it. So...

If you're simply invoking docker compose to interact with things, then I'd say store the compose files where ever makes the most sense for your process. Maybe think about setting up a specific directory on your NFS share and mount that to your docker host(s). I would also consider version controlling your compose files. If you're concerned about secrets, store them in encrypted env files. Something like SOPS can help with this.

As long as the user invoking docker compose can read the compose files, you're good. When it comes to mounting data into containers from NFS.... yes permissions will matter and it might be a pain as it depends on how flexible the container you're using is in terms of user and filesystem permissions.

Docker's documentation for supported backing filesystems for container filesystems.

In general, you should be considering your container root filesystems as completely ephemeral. But, you will generally want low latency and local. If you move most of your data to NFS, you can hopefully just keep a minimal local disk for images/containers.

As for your data volumes, it's likely going to be very application specific. I've got Postgres databases running off remote NFS, that are totally happy. I don't fully understand why Plex struggles to run it's Database/Config dir from NFS. Disappointingly, I generally have to host it on a filesystem and disk local to my docker host.

In general, container root filesystems and the images backing them will not function on NFS. When deploying containers, you should be mounting data volumes into the containers rather than storing things on the container root filesystems. Hopefully you are already doing that, otherwise you're going to need to manually copy data out of the containers. Personally, if all you're talking about is 32 gigs max, I would just stop all of the containers, copy everything to the new NFS locations, and then re-create the containers to point at the new NFS locations.

All this said though, some applications really don't like their data stored on NFS. I know Plex really doesn't function well when it's database is on NFS. But, the Plex media directories are fine to host from NFS.

In a centralized management scenario, the central controlling service needs the ability to control everything registered with it. So, if the central controlling service is compromised, it is very likely that everything it controlled is also compromised. There are ways to mitigate this at the application level, like role-based and group-based access controls. But, if the service itself is compromised rather than an individual's credentials, then the application protections can likely all be bypassed. You can mitigate this a bit by giving each tenant their own deployment of the controlling service, with network isolation between tenants. But, even that is still not fool-proof.

Fundamentally, security is not solved by one golden thing. You need layers of protection. If one layer is compromised, others are hopefully still safe.

If we boil this article down to it's most basic point, it actually has nothing to do with virtualization. The true issue here is actually centralized infra/application management. The article references two ESXi CVE's that deal with compromised management interfaces. Imagine a scenario where we avoid virtualization by running Kubernetes on bare metal nodes, and each Pod gets exclusive assignment to a Node. If a threat actor has access to the Kubernetes management interface, and can exploit a vulnerability to access that management interface, it can immediately compromise everything within that Kubernetes cluster. We don't even need to have a container management platform. Imagine a collection of bare-metal nodes managed by Ansible via Ansible Automation Platform (AAP). If a threat actor has access to AAP and exploit it, it then can compromise everything managed by that AAP instance. This author fundamentally misattributes the issue to virtualization. The issue is centralized management and there are significant benefits to using higher-order centralized management solutions.

Perhaps as the more experienced smoker, you can be a good friend and offer a lower dose that is more suited for their tolerance. Maybe don't pack a big-ol bong rip for someone who hasn't smoked in months. Chop up that chocolate bar into something a little more manageable. If they wanna buy something, suggest something a little more controllable like a vape. And most of all, if you're pressuring people who are on the fence into smoking, maybe just stop doing that.

Yea, I don't think this is necessarily a horrible idea. It's just that this doesn't really provide any extra security, but even the first line of this blog is talking about security. This will absolutely provide privacy via pretty good traffic obfuscation, but you still need good security configuration of the exposed service.

If I understand this correctly, you're still forwarding it a port from one network to another. It's just in this case, instead of a port on the internet, it's a port on the TOR network. Which is still just as open, but also a massive calling card for anyone trolling around the TOR network for things to hack.

This isn't about social platforms or using the newest-hottest tech. It's about following industry standard practices. You act like source control is such a pain in the ass and that it's some huge burden. And that I just don't understand. Getting started with git is so simple, and setting up an account with a repo host is a one time thing. I find it hard to believe that you don't already have ssh keys set up too. What I find more controversial and concerning is your ho-hum opinion on automated testing, and your belief that "most software doesn't do it". You're writing software that you expect people to not only run on their infra, but also expose to the public internet. Not only that, but it also needs to protect the traffic between the server on public infra and client on private infra. There is a much higher expectation of good practices being in place. And it is clear that you are willingly disregarding basic industry standard practices.

Github and Gitlab are free, and both even allow private repos for free at this point. Git is practically one of the first tools I install on a dev machine. Likewise, git is the defacto means of package management in golang. It's so built in that module names are repo URLs.