I've been using Canonical's LXD for this, under Debian Trixie. Nowadays I can usually get away with just running containers for things I need vs full-blown VMs. I guess the only downside is that in order to get the latest version of LXD installed easily you'd have to do it via snap, which I understand is a dealbreaker for many.
There's also been advancements in cylinder head technology (i.e., VTEC, VVT, etc), which I guess also falls under control systems, but worth mentioning as these technologies are very cool. Honda's iVTEC has it down to a damn science with how to optimize valve lift & duration across the entire RPM spectrum.
When you setup your single ethernet port (let's call it eth0) as a VLAN trunk port, you'll get the ability to configure multiple virtual interfaces off of it. How many virtual interfaces you get depends on how many VLANs you want to tag traffic for. For example, if you have 2 VLANS with ids 100 and 200 (100 being your public Internet-facing traffic, and 200 being your LAN traffic), you would then have interfaces eth0.100 and eth0.200 to work with that you can then use in your firewall scripts as if they were two separate, physical interfaces.
This of course means you need a VLAN-aware switch that this single ethernet port can plug into, configured as a VLAN trunk (in Cisco terms) port. You would then want to configure one of the other switch ports as a VLAN access port assigned to VLAN 100 (untagged). This is the port you would plug your cable modem into. Then (in the simplest example) you could assign all the rest of the switch ports to VLAN 200 (untagged), and you would plug all your LAN devices into them.
Yes. You can take advantage of Netfilter's flowtable infrastructure and if you have the right hardware (NVIDIA/Mellanox ConnectX-5 or MediaTekMT7621) it will actually offload the processing of these packets to the NIC hardware. This only applies to established connections, however, but that typically accounts for like 95% of the traffic passing through.
You can still use the iptables interface for nftables rules if you'd like, but I think you miss out on things like atomic application of rulesets, ranges, lists, and variables (not shell variables).
- PCEngines APU (x86, AMD T40E) (my current router/firewall) (discontinued)
I'm also currently using an APU2 as one of my wireless access points (with hostapd).
All of these have been solid machines that have given me zero problems.
The next system I plan to use is going to be a Banana Pi R4 (ARM Cortex A73), it's a solid choice for a simple router/firewall/DNS/DHCP box. It has a built-in 4-port gigabit switch where each interface can be used as normal Linux interfaces, as well as 2 SFP+ ports that are capable of supporting up to 10 gig ethernet.
It's also one of the few systems that offers true hardware offloading for connection tracking, so things like netfilter flowtables don't have to use any main CPU processing.
I'm currently experimenting with a Banana Pi R4 as a Wifi7 access point (running Debian with hostapd), however the current state of the wifi7 module for it (BPI-R4-NIC-BE14) and Linux driver (mt7996e) is still pretty young and a bit buggy (i.e., limiting transmit power to 6 dBm without patching the driver to override it, and there's apparently a lack of RF shielding which can contribute to low SNR on the receiving end). With the proper patches in place it makes a decent Wifi 6 access point. I'm hoping these issues get ironed out in the future and I can use it as a true Wifi7 AP. frank-w is doing outstanding work to help support the open source community with this new hardware.
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.
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.
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: