One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.
Unfortunately, I think that's likely the case for anyone on the younger side. Most of that came to light in 2013, 13 years ago. Anyone 20-30 years old today would've been a teenager then in high school, and likely not paying attention very closely.
It was big news for a little bit, and then the media by design quickly forgot about it barely a year later, and that is why history is doomed to repeat.
Here's a fun one that I still haven't figured out:
I recently purchased a Banana Pi 4 with the 802.11be Wi-Fi 7 module to be used as an access point. It generally works well as an AP and I'm getting full speeds. However, for some reason whenever I try to communicate directly with the router/firewall (separate device on the same network) through this AP, it will intermittently drop 3/4 packets. It only happens when communicating with the router/firewall device, and only over the wlan interface on the bpi-r4. I have a similar AP setup on another embedded system (PCEngines APU2) and this has never been an issue.
I suspect there's some sort of bug with the internal 4-port switch of the bpi-r4 not playing well with the wlan interface when they're all bridged together, but digging through the logs hasn't revealed anything obvious.
I was able to accomplish this by doing each test within its own transaction session that gets rolled-back after each test. This way I'm allowed to modify the database to suit my needs for each test, then it gets magically reset back to its known state for the next test. Transaction rollbacks are very quick.
Unfortunately a lot of our tests use transactions themselves because we lock the user row when we do anything to ensure consistency, and I'm pretty sure nested transactions are still not a thing.
Migrations are kind of a different beast. In that case I just stand up a test environment in Docker that does what it needs, then just trash it once things have been tested/verified.
This is kind of a complicated example, but here goes:
Say we want to create a report that determines how long a machine has been down, but we only want to count time during normal operational hours (aka operational downtime).
Normally this would be as simple as counting the time between when the machine was first reported down, to when it was reported to be back up. However, since we're only allowed to count certain time ranges within a day as operational downtime, we need a way to essentially "mask out" the non-operational hours. This can be done efficiently by finding the intersection of various time ranges and summing the duration of each of these intersections.
In the case of PostgreSQL, I would start by creating a tsrange (timestamp range) that encompases the entire time range that the machine was down. I would then create multiple tsranges (one for each day the machine was down), limited to each day's operational hours. For each one of these operational hour ranges I would then take the intersection of it against the entire downtime range, and sum the duration of each of these intersecting time ranges to get the amount of operational downtime for the machine.
PostgreSQL has a number of range functions and operators that can make this very easy and efficient. In this example I would make use of the '*' operator to determine what part of two time ranges intersect, and then subtract the upper-bound (using the upper() range function) of that range intersection with its lower-bound (using the lower() range function) to get the time duration of only the "overlapping" parts of the two time ranges.
Here's a list of functions and operators that can be used on range types:
One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.
reply