• 1 Post
  • 56 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.





  • 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









  • Everyone’s gotta start somewhere. I do know that it’s not easy for trans men to get a well-fitting suit. I’m familiar with one case where the tailor sent the suit back without any alterations, because they thought the body proportions given by the shop were a mistake. That was rather infuriating to see, but it worked out in the end. I guess what I’m saying is that you should give yourself plenty of time in advance to get your next suit. It may not be the “come back in a week for pickup” that most men are used to.

    Hell, I know a cis guy who had to visit 8 different places to find a suit that fit him. He’s a normal looking guy, but the proportions between his hips and waist was somehow an outlier for 99% of the pants he tried on.





  • Despite what the length of their privacy policies might suggest, first party sites are a lot stingier with their user data now than they’ve been in the past. The value of knowing who someone is and what they want is derived when you convince them to pull out a credit card, at which point you need to collect their data anyway.

    Thus, I think we’ll see two tiers of data collection: Deep first-party info shared between retailers and data brokers to target advertising on their first party site, and less granular banner advertising based on privacy sandbox, taking the place of drive-by cookie drops. If privacy sandbox is as good for random blogs as industry is expecting (ie, not as perfect as third party cookies, but less impactful than Apple’s ITP was), I don’t think we will see a wave of email signups.


  • I don’t quite understand the leap from “No third party cookies” to “You need to create an account”.

    If you’re visiting a site and they drop a cookie, that’s a first party cookie. You don’t need to log in for that to happen, and they can track you all the same. Taking identifiers from a first party cookie and passing them to advertisers will still be a thing, it’ll just require closer coordination between the site and the advertiser than if the advertiser dropped their own cookie.

    Now yes, that first party cookie won’t follow you around to other websites and track your behavior there, but creating an account wouldn’t enable this anyway. Besides, Google’s Privacy Sandbox product suite is intended to fill this role in a less granular way (associating k-anonymized ids with advertising topics across websites).