• 9 Posts
  • 103 Comments
Joined 1 year ago
cake
Cake day: June 16th, 2023

help-circle


  • For backup, maybe a blu-ray drive? I think you would want something that can withstand the salty environment, and maybe resist water. Thing is, even with BDXL discs, you only get a capacity of 100GiB each, so that’s a lot of disks.

    What about an offsite backup? Your media library could live ashore (in a server at a friend’s house). You issue commands from your boat to download media, and then sync those files to your boat when it’s done. If you really need to recover from the backup, have your friend clone a disk and mail it to you.

    Do you even need a backup? Would data redundancy be enough? Sure if your boat catches fire and sinks, your movies are gone, but that’s probably the least of your problems. If you just want to make sure that the salt and water doesn’t destroy your data, how about:

    1. A multi-disk filesystem which can tolerate at least 1 failure
    2. Regular utilities scanning for failure. BTRFS scrubs, for example.
    3. Backup fresh disks kept in a salt and water resistant container (original sealed packaging), to swap any failing disk, and replicate data from any good drives remaining.
    4. Documentation/practice to perform the aforementioned disk replacement, so you’re not googling manpages at sea.

    This would probably be cheapest and have the least complexity.




  • You’ve laid out one potential development cycle: FOSS from the get-go, and open collaboration welcome.

    However, that’s not the only way that a FOSS game might be developed. The code could be freely licensed, but the upstream developers refuse to accept outside patches. In that case, there’s one “original” and then if you don’t like it, build your fork.

    Alternatively, a game could be developed entirely in-house under proprietary licenses, and then only made FOSS upon commercial release. Contributor patches could improve the project, but conception of the game would be entirely the domain of its original developers.


  • How about writing a script to automate the deletion, thus minimizing the chance of human error being a factor? It could include checks like “Is this a folder with .git contents? Am I being invoked from /home/username/my_dev_workspace?”

    In a real aviation design scenario, they want to minimize the bullshit tasks that take up cognitive load on a pilot so they can focus on actually flying. Your ejector seat example would probably be replaced with an automatic ejection system that’s managed by the flight computer.






  • As others have said, a reverse proxy is what you need.

    However I will also mention that another tool called macvlan exists, if you’re using containers like podman or docker. Setting up a macvlan network for your containers will trick your server into thinking that the ports exposed by your services belong to a different machine, thus letting them use the same ports at the same time. As far as your LAN is concerned, a container on a macvlan network has its own IP, independent of the host’s IP.

    Macvlan is worth setting up if you plan to expose some of your services outside your local network, or if you want to run a service on a port that your host is already using (eg: you want a container to act as DNS on port 53, but systemd-resolved is already using it on the host).

    You can set up port forwarding at your router to the containers that you want to publicly expose, and any other containers will be inaccessible. Meanwhile with just a reverse proxy, someone could try to send requests to any domain behind it, even if you don’t want to expose it.

    My network is set up such that:

    • Physical host has one IP address that’s only accessible over lan.
    • Containerized web services that I don’t want to expose publicly are behind a reverse proxy container that has its own IP on the macvlan.
    • Containerized web services that I do want to expose publicly have a separate reverse proxy container, which gets a different IP on the macvlan.
    • Router has ports 80 and 443 forwarding only to the IP address for my public proxy

  • Yes, it’s the ratio of how much of the power that you transmit is reflected back towards your rig due to impedence mismatch of antenna <-> radio.

    Ideally you want SWR < 2, but for simple voice modes at QRP power, it’s not the end of the world if you end up in the 2-3 range. However digital modes need a good SWR because they transmit at 100% duty cycle. If I don’t get SWR < 2 for my IC-705 during a digital transmit, the reflected power causes my computer’s USB port to reset. At higher powers it could damage my rig or my computer, so it’s definitely a thing to avoid.


    1. Hard to recommend, because it will depend on preferences. I went with a QRP Icom IC-705 because I knew I wanted to go hiking and do POTA with it. I will say that 10W can feel very limiting, and it can be tough to make the same contacts that others can easily hit. If down the line you want a stronger transmitter, you’d need to get an amplifier. The overall cost of QRP rig + amp might be more than a “base station” type model with higher xmit power out of the box. Again it all depends on your preferences. At the very least, I’d recommend something with good voice and digital mode performance. Plugging right into WSJT-X or JS8Call for digital is super fun, and I like it a lot more than talking to folks.

    2. Never done a build project for xceiver, so I couldn’t say. All those 10W systems can always be amplified for more output.

    3. That’s called a random wire antenna. It’s what I currently use when taking my rig out on the go. It consists of an antenna line and a counterpoise joined by a 9:1 unun (not balun). Keep it away from other metal parts like roof gutters or fences. The wire length isn’t actually “random”, but you can find tables online where people test for a length that gets ok SWR on several bands. You will still need an impedence matcher (aka “antenna tuner”) to actually get a usable SWR.