• 27 Posts
  • 657 Comments
Joined 1 year ago
cake
Cake day: June 4th, 2023

help-circle
  • Lot of people saying they don’t give internet access to their TVs.

    Fine, but that doesn’t work for cord-cutters who opted out of cable to go with streaming. And if you keep your TV away from internet but have a cable box, it will be doing all the tracking in this paper (and worse) then sending it to the cable provider.

    So short of sticking with DVD/Bluray (unconnected) or over-the-air broadcast TV, there’s no way to stop from getting tracked.

    The paper also lists domains where the data is being sent. You could always try blocking the destination addresses at the router level.







  • fubarx@lemmy.mltoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    2 days ago

    OK, you wanted a conversation… :-)

    I did read the post, but I assumed it was the starting point of a system or mechanism, not the end-point. Wanting to just run “docker compose up” is fine, but there is more to developing and deploying to production (and continuing post-launch).

    That’s why I mentioned the CLI. It lets you go from a simple local app (Django on sqlite) to a Docker one (postgres, celery, redis, etc.), to all the way out to the cloud (ECS/EKS/serverless lambda/RDS), without having to remember what commands do what or managing lots of separate docker-compose files.

    I can see we are VERY far apart on how docker should be used in moving toward a production-ready system.

    For one thing, recommending putting secrets inside docker-compose is an instantly disqualifying piece of advice. There’s a whole ‘secrets’ section of docker compose that is there to prevent people from inadvertently including those in cleartext and baking them into images: https://docs.docker.com/compose/how-tos/use-secrets/.

    Github itself has a secret scanning mechanism to prevent leakage: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning. For gitlab, there’s also Blackbox or HashiCorp vault. Putting AWS key/secret inside a repo can be VERY expensive and open one to legal liability if the account is misused. Repeated infractions could lead to AWS banning one’s account.

    I really recommend you take down that part of your post, instead of proliferating bad practices.

    As for the rest, to each their own.



  • fubarx@lemmy.mltoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    2 days ago

    Good stuff.

    A few things I’d change:

    • A CLI to simplify local vs docker vs cloud operations. Reduces chance of operator error. Have had good luck with python click library.
    • Moving config settings into separate JSON and .env files to avoid loading too many config and secrets in the docker-compose file.
    • For AWS, I’d go with CDK. That way, cloud deployment is all in python (or typescript).
    • For cloud, you can also package Django into a single lambda, with dependencies inside a lambda layer. Not sure I’d use it in heavy production, but for small apps, really handy.
    • Inside Django settings, you can switch DB and services whether running local (sqlite, Redis), docker (postgres, RabbitMQ), or cloud (RDS, SQS).









  • First they switched to the mini-spares. Then they got rid of them altogether.

    If you’re lucky, there are little filler canisters and a cigarette lighter-powered air compressor to let you get slowly to a tire shop. Sometimes, not even that. If there’s a nail or a blowout, tow-truck city. Just hope it’s not out in the middle of nowhere in the dark or in bad weather.