Apologies if this is a common question - Lemmy search leaves a little to be desired still.
How exactly does a Thread border router talk to edge devices? Do they talk directly, device-to-device or will a border router utilize the 2.4GHz radios in my APs to extend its range?
What are your thoughts on TrueNAS Core or Unraid instead of Synology? I could still run Plex on the same hardware that handles the storage while maintaining the freedom and flexibility that my current home lab server provides. There appears to be plenty of decommissioned enterprise-grade hardware being sold on FB all the time.
Again, pardon my ignorance when it comes to Kubernetes. Why would I use something like k0s instead of just regular old Docker? I suspect PCIe passthrough will have similar challenges on both k0s and Docker, whereas on Proxmox it's been relatively painless.
This might be better suited for a different community, in which case I'll make a post where appropriate. I'm not familiar with some of the Kubernetes terminology - batteries, pod/manifest (is this similar to stacks/docker compose?), NodePort?
I apologize for my ignorance when it comes to Kubernetes - I sort of wrote it off as complete overkill for a home lab when my very basic understanding was that it was essentially a load balancer. After some light research, I'm beginning to understand that it could be a better solution than a full-blown hypervisor.
If I understand your comment correctly, you're suggesting to simply run a lightweight distro and install k0s or k3s to run containers? What would be an ideal bare metal OS for this? What would be pros/cons to k0s vs k3s in a home lab environment, or is that simply a matter of personal preference? What would be the best way to connect to my media - SMB, NFS, something else? Or are the differences here irrelevant? Any concerns (permissions, IO latency) when passing an NFS mount from host into a container, or is there an even better way to do something like that entirely within the container?
I’m looking for some feedback on my Plex system architecture.
All my media is stored on a Synology DS 1621+, six 4 TB drives in RAID 6 with one acting as a hot spare. All four network ports are bonded into a 4G link to an Ubiquiti USW-48-POE.
Previously, I ran Plex in a Docker container on the NAS. This setup was stable; however, the NAS only has 4 GB of memory shared between Plex, several other Docker services, and regular DSM overhead. Plus, the processor is not very powerful (AMD Ryzen V1500B, ~5400 PassMark).
A few months ago I repurposed some old desktop PC parts to build a home lab Proxmox server (Core i7-6700K [~8900 PassMark], 32 GB memory, GTX 970, an old 2.5” SATA SSD for guest OS disks, 1G networking on the motherboard). I’m running Plex on an Ubuntu VM, with the GPU passed through directly to the guest OS. Plex is not containerized in Ubuntu. The VM has 8 CPU cores and 8 GiB memory (different units in Proxmox). My Plex media is accessed via a persistent NFS mount in Ubuntu (had been SMB before a DSM update broke something and the VM could no longer read the directory contents.)
The main purpose of the change from NAS to VM was to utilize the increased CPU/GPU horsepower and memory that I had lying around, but I worry that the added layers of complexity (hypervisor/VM, PCIe pass through, NFS mounts) will introduce more opportunities for performance issues. I have noticed more frequent hiccups/buffering/transcoding since the change but I’m not sure if it’s related to my setup or if those issues lie with client devices and/or the files themselves (e.g. weird file container type that the client can’t play natively).
Any critique or recommendations on system architecture? Should I get a dedicated NIC to pass through to my VM? Dedicated NVMe drive passed through as a guest OS disk? Ditch Proxmox altogether and go back to Synology Docker container?
First you have to convince him that the earth is more than 8000 years old.
The Fn and Carl keys can be switched in software. I have a work-issued Lenovo with a similar layout. They can be soft-swapped in the BIOS. There’s also a desktop utility to do the same but I don’t know if they have a Linux version of it. I totally agree, the physical layout is annoying but it has a simple fix.
Then this is false advertising and a class-action lawsuit that should have already happened.
This Arstechnica article seems to confirm that they can't decrypt without user intervention and that they have only ever supplied metadata to law enforcement. I'm no fan of Meta but do you have sources that they have in fact decrypted actual message content at the request of law enforcement?
No disagreement there. I could have clarified, my comment was in regard to message content only. I didn't realize that about metadata and certainly am not defending Meta. I'd prefer Signal over anything else but as others have mentioned, getting friends and family to adopt is painful.
It’s still E2EE, as far as I know. Meta could always remove that feature but until they do, I’d consider it a safe and private messaging platform.
Realistically, fines or other regulations that has the effect of increasing their costs. The way it should work is that this would increase costs to consumers, who then buy less or buy from a competitor who doesn’t pollute as much. But too many people think that any regulation whatsoever is communism and scream whenever anything like that is talked about so nothing ever gets done. And also the politicians are bought.
I thought I had read, several years ago, that Apple dumps a bunch of money into R&D of new tech in exchange for exclusive use of that tech for a period of time after it hits the market (e.g. ultra high-res displays on the iPhone 4). Seems like they haven’t done that as much in recent years but I’ve been patiently waiting for graphene batteries. Maybe this is the year 🤞
I thought I had read, several years ago, that Apple dumps a bunch of money into R&D of new tech in exchange for exclusive use of that tech for a period of time after it hits the market (e.g. ultra high-res displays on the iPhone 4). Seems like they haven’t done that as much in recent years but I’ve been patiently waiting for graphene batteries. Maybe this is the year 🤞
This morning I updated my DS1621+ from DSM 7.1.1-42962 U6 to DSM 7.2-64570 U1. After the update I am no longer able to access shared folders from my Ubuntu machine. All errors in terminal and Portainer indicate "access denied", though no passwords have changed, and I am still able to access the shared folders from Windows. I am mounting shared folders with SMB but also tried NFS when SMB stopped working, as that appears to potentially be easier to manage (no usernames/passwords?).
Any help or direction to a fix is greatly appreciated.
EDIT: Realized I had a typo in my mount command for mounting an NFS share - I was using ip.address:/shared_folder instead of ip.addres:/volume_name/shared_folder. Fixed that and now have no problems using NFS to mount the shared folders to the same mount point as before, so for me that's a suitable workaround and presumably a better solution than SMB anyway, since both client and server are Linux OSes anyway.
Short answer: no
Long answer: the percentage of drivers that are outrageously bad at driving is probably a fraction of a percent. This still equates to a very large number of drivers, but there is also very much a bias at play. You only ever see videos of shitty drivers and probably never see videos of good drivers which skews your view of how good or bad the general population is at driving.
All this to say, yes there are a very large number of lethally dangerous drivers, but several orders of magnitude more drivers who are not. You just don’t notice them because they aren’t bad drivers.
This is fantastic news. I’m currently using HomeKit + Homebridge for all my smarthome stuff but I have HA Core running on a Proxmox host in the event I need/want to migrate. Apple continues to let me down year after year with their minimal Home updates but convincing my family to switch is a hurdle I’m not ready to tackle yet.