At home, my "NAS" is the Linux desktop box under my desk. It's got a bunch of local drives doing ZFS things, and samba.
I could split up the functions into different boxes and build a faster LAN to connect them, but doing that wouldn't improve anything except giving me more parts to goof around with. :)
I've read through your story and I think you're on the right track with what you're doing.
But, re: alarms, I'd like to add a suggestion: Indoor sirens. They can be intolerably, painfully loud for not very much money (because piezos are cheap and square waves are easy). Using a small, random mixture of them can let them beat at different frequencies and periods, which can make them very unpleasant to behold even with hearing protection.
If you feel like being clever, you can even run them with a local battery that activates when they're disconnected. If you feel like being extra-clever, you can make them activate when they don't have the correct termination resistance at the far end of the line, or exactly the correct voltage: This way, whether the wire goes open or short, the sirens activate.
Super-extra bonus points for using a combination of methods. Any time that a thief spends figuring this out is time they aren't carrying stuff out.
And if that still seems incomplete, then: Fill the shop with smoke. They can't function when they can't even see their hand in front of their face. https://www.youtube.com/watch?v=RPgcysyFUiI
Some years ago, there were mud-slinging myths being thrown around about ZFS.
Things like "ZFS needs 1GB of RAM per 1TB of storage" and "it requires that RAM to be ECC" were once common to find online.
These sort of thing seemed to lead to widespread beliefs that it was inefficient, expensive, and fragile. None of that is true, of course, but folks might remember and believe these myths and conclude that it is (or was) bad.
(But it's pretty excellent. I've been using it for about a decade, now. It'd be nice if it fit into the Linux kernel better, but I manage anyway.)
Yep. They be wrong. Many of the myths about ZFS seem to originate from the TrueNAS forums, and the working assumption is that they're motivated to be this way because they're a bunch of gatekeeping losers.
More RAM is better -- of course it is. Otherwise-unused RAM can gets used for stuff like caching (such as the ZFS arc), and caches are faster than disks. That's good for performance.
But ZFS isn't really any more thirsty in this way than other filesystems are, unless special features -- stuff that many other filesystems lack entirely, like deduplication -- get used.
And these days, dedup can use an SSD instead of RAM for the heavy lifting so that's not a huge concern either. (Not that I'm recommending dedup; it works and it is reliable, but it doesn't fit very many workloads.)
I would absolutely be comfortable running ZFS with 12TB on 6GB. Or 2GB, for that matter. It's fine. Send it.
I've personally done more with less and had excellent results. No regrets.
(There's ways to tune arc performance, too. As an example, I've got a dataset that is full of many terabytes of Linux ISOs. I don't need that data to be cached...like, ever. If it were to be cached, it would just consume resources that would be better spent elsewhere. But I do want it to be indexed quickly. So I set that dataset to primarycache=metadata and that works great for me.)
TrueNAS is an OS with management bells and whistles. I'd say yeah you'd want 16GB for TrueNAS to work well, ie roughly 8GB for TrueNAS and roughly 8GB for ZFS cache.
No you do not need 16GB simply for a 12TB ZFS array on a plain Linux/FreeBSD box. It'll be faster, but you don't need it.
Thanks, I think. I usually write UBNT because it's distinct and spelling out "Ubiquiti" hurts my soul in ways that I find difficult to properly articulate.
The processing can happen within the camera, and it's nice when it does...but that doesn't mean that the only other option is something cloud-based, like some might assume.
Open-source NVR software like Frigate can do things like the object-detection/license plate/face recognition game on local hardware, with the cheapest available IP cameras. It's just a program that runs on a computer with a network and some storage and some processing ability like a GPU.
Those cheap cameras don't have to be trusted; with things like VLANs, they can hang out on the Group W bench where they have no access to anything important or the outside world. :)
(But yeah, it does represent much more of a DIY effort than something from UBNT does.)
There was a time when a person could walk through a few department stores every week (or even every day) just to take note of some prices along the way, and ultimately tabulate them to try to identify and snatch up the best deal once it happens.
And if everyone did this, it'd be a real problem. The stores would be clogged up by geeks writing notes in little books with Parker Jotters and just basically wasting space and taking up air conditioning while they sleuth out the best way to put the screws to the company for a few measly dollars.
That'd be awful.
But not many people ever did that in stores, and not many individual people are doing that today with the web. It's really not a problem.
(And if a website in 2026 can't stand the burn of several thousand personal scrapers that are operated by people who actually want to buy stuff from it, then maybe that system simply sucks and needs to be rethought.)
> There was a time when a person could walk through a few department stores every week (or even every day) just to take note of some prices along the way, and ultimately tabulate them to try to identify and snatch up the best deal once it happens.
This is how it started! I noticed certain things during my weekly shop that I did a double-take on and thought "wasn't that $cheaper last week!?". Took me ~ 45 min to figure out that the retailer actually has a really nice graphQL endpoint that powers the "view your previous receipts" function on their website. Of course they don't document this / make it available for 3rd parties... so scrape it is!
I wrote a bot to dump every receipt into a sqlite DB and I fire it up ~ weekly to pull down receipts that it doesn't have locally.
Turns out, not _everything_ has gotten more expensive @ my local grocery store over the past few years... just most things have :/.
> But not many people ever did that in stores,
There's a cottage-industry of firms out there that get gig-workers to pop in to $randomStore and take a picture of $randomItem on shelf w/ the price tag in the photo. The firms sell this info to stores that want to know how a competitor might be doing pricing / placing certain items on the more valuable shelf spots.
> and not many individual people are doing that today with the web. It's really not a problem.
That's my point! I scrape a few hundred pages per day across _many_ domains. My bots respect 429s and they have some other backoff/random-jitter strategies baked in to _not_ be the reason anti-scrape proliferates.
Please accept all possible encouragement. This is exactly the kind of personal project that a world wide web of network-connected computers is supposed to enable.
(I have no idea how it is that so many of us here have come to lose the plot.)
The built-in, offline mapping in my Honda uses a whole host of local-only sensors to handle these situations where GPS is intermittent. It works rather well at figuring out where the car is on the map, and when it deviates from the prescribed route.
It works in tunnels. It works in cities with tall buildings. It works on Lower Wacker Drive in Chicago.
Is there some technological limitation that precludes using this data to determine whether or not a movie can be played?
(It's not like it's new tech. It's decades-old. Honda started using it over 20 years ago.)
There's no need when OBD does just fine for this purpose.
It's also not clear what the purpose of this line of argument is. Some sensor says "car is moving". The operating system in the car/head unit is responsible for enforcing that signal, and it could ignore it equally from either OBD or some pile of gyroscopes. Where that signal comes from has nothing to do with why you will not see cars accepting custom operating systems.
> It's also not clear what the purpose of this line of argument is.
It completely dismantles your previous goalposts, which were planted firmly on GPS:
>> Not with the necessary precision. GPS doesn't work in tunnels or parking garages and can be wildly inaccurate in city centers with skyscrapers blocking line of sight, for instance.
(I guess we all have the freedom to be as flexible with our goalposts as we wish. I didn't come here for a tireless argument that is motivated by nothing but the desire to argue, though. Have a great day!)
My line of argument is "the head unit is responsible for not allowing video playback while in motion". Anything to do with detecting motion came after that.
The point of argument is that it no longer becomes a security issue to allow customOS on the infotainment system because it absolutely has no connection to the engine computer.
This is not an architectural issue. The threat isn't a bad OS causing the car to explode. This is a safety issue where the car is required to prohibit certain things - such as video playback.
In the States, for example: Every state I've looked at has laws that make it illegal to roll coal.
And at least in my own state (Ohio), it's a primary offense. A person can be pulled over and ticketed for this even if they're doing everything else by the book. It's super easy to spot.
It seems that it persists not because of a lack of laws, but because of a lack of enforcement.
Even if it isn't stapled: Good chance that it has turns inside of walls, floors, and/or ceilings that are impossible to successfully pull new wire through without creating new access for someone to get their hands in there.
Residential low-voltage cable plants are almost never implemented in a way that makes upgrades simple.
I could split up the functions into different boxes and build a faster LAN to connect them, but doing that wouldn't improve anything except giving me more parts to goof around with. :)
reply