Yep.
I have friends in the SMB space, one thing they do is a regular backup verification (quarterly). At that frequency, restoring even a few files (especially to a new VM), is very indicative, especially if it’s a large dataset (e.g. Quickbooks).
In Enterprise, we do all sorts of validation, depending on the system. Some is performed as part of Data Center operations, some is by IT (those are separate things), some by Business Unit management and their IT counterparts.
Performance may be an issue. It’s not specifically designed for streaming performance, and being a software VPN, it will depend a great deal on the devices used at each end.
Great summary!
Why Debian or Ubuntu? (I have my own thoughts, but it would be useful to show even high-level reasons why they’re preferred).
Re: Backup - Backblaze has a great writeup on backup approach today. I’m a fan of cloud being part of the mix (I use a combo of local replication and cloud, to mitigate different risks). Getting people to include backup from the start will help them long-term, so great you included it!
It’s up to the squatter to actually spend the time and money to sue though.
A C&D is a letter from a lawyer to stop or they’ll sue, it’s not a court order.
Yea, if you use Tailscale with Funnel, you get a secure connection with no config required by the web user.
Not seeing why you need WordPress.
The safest way I can see to make a secure connection across an untrusted network is to use a VPN of some sort, specifically a mesh network like Wireguard or Tailscale.
Tailscale has the advantage of being almost zero config, plus has the Serve and Funnel features which provide a mechanism to allow specific traffic into your Tailscale network.
Edit: Tailscale Serve is probably what I’d use.
After (ugh) 30 years of having PCs and many, many, drives, Seagate has been the worst.
But I’ve had WD fail too. Just not as much, and I’ve had far more WD drives. I currently have about 20 drives of varying ages, 98% of them are WD, because more of the Seagate drives have failed and been trashed.
And backup, proper backup.
My only issue with Grayjay (both Android and Windows app), is you have to manually export the videos out of Grayjay
If you try to grab the files directly, they don’t work.
Syncthing
Windows - Synctrayzor
Linux - Syncthing
Android - Syncthing-Fork
iOS - Möbius
Ooh, good Ole malicious compliance.
Make it a check.
Even better, pay with visa. The processing fee will be more than 23¢
“raw dogging the Internet”… I chuckled out loud
One day, after I am done with -insert reason here-, I will have a bad ass, well thought out backup solution.
For some reason you’re “insert reason here” was dropped by lemmy. I guess a sequential less-than/greater-than messes with it.
So you have nothing to hide, eh?
These tvs, like smartphones, track lots of stuff. And the databases they feed make all sorts of inferences.
They even scan what you’re watching from other sources and can determine what show it is, and report that info too.
They know when you’re home and leave, to some extent.
I’ve read of patents for wifi tech in tvs that will connect to other TVs of the same brand for a connection if you don’t set one up.
They definitely use their own DNS, and probably have some hard coded IPs so you can’t block them phoning home via DNS (I’ve tested this myself). I can see this traffic even when I setup DNS blocks - they still hit the vendor’s service IPs (looking at you, Samsung).
These companies are openly antagonistic and adversarial to us, and you “have nothing to hide”?
Another hero we didn’t know we needed.
Have my grateful uovote.
Very good point about Agile.
As an end-user (that is, the IT staff that will be deploying/managing things), I prefer less-frequent releases. I’d love to see 1 or 2 releases a year for all software (pipe dream, I know). Once you have a handful of packages, you end up with constant change to manage.
I suspect what we end up with is early adopters embracing the frequent releases, and providing feedback/error reporting, while people like me benefit from them while choosing to upgrade less frequently.
There are about 3 apps that I’m a beta tester for, so even I’m part of that early-adopter group.
Documentation has been mentioned already, what I’d add to that is planning.
Start with a list of high-level objectives, as in “Need a way to save notes, ideas, documents, between multiple systems, including mobile devices”.
Then break that down to high-level requirements such as “Implement Joplin, and a sync solution”.
Those high-level requirements then spawn system requirements, such as Joplin needs X disk space, user accounts, etc.
Each of those branches out to technical requirements, which are single-line, single-task descriptions (you can skip this, it’s a nice-to-have):
“Create folder Joplin on server A”
“Set folder permissions XYZ on Joplin folder”
Think of it all as a tree, starting from your objectives. If you document it like this first, you won’t go doing something as you build that you won’t remember why you’re doing it, or make decisions on the fly that conflict with other objectives.