• 2 Posts
Joined 1 year ago
Cake day: July 9th, 2023


  • I think this a problem with applications with a privacy focused user basis. It becomes very black and white where any type of information being sent somewhere is bad. I respect that some people have that opinion and more power to them, but being pragmatic about this is important. I personally disabled this flag, and I recognize how this is edging into a risky area, but I also recognize that the Mozilla CTO is somewhat correct and if we have the option between a browser that blocks everything and one that is privacy-preserving (where users can still opt for the former), businesses are more likely to adopt the privacy-preserving standards and that benefits the vast majority of users.

    Privacy is a scale. I’m all onboard with Firefox, I block tons of trackers and ads, I’m even somebody who uses NoScript and suffers the ramifications to due to ideology reasons, but I also enable telemetry in Firefox because I trust that usage metrics will benefit the product.

  • Why is telemetry useful or why is it needed to use pi-hole to block telemetry?

    Telemetry is useful to know what features your customers use. While it’s great in theory to have product managers who dogfood and can act on everyone’s behalf, the reality is telemetry ensures your favorite feature keeps being maintained. It helps ensure the bugs you see get triaged and root caused.

    Unfortunately telemetry has grown to mean too many things for different people. Telemetry can refer to feature usage, bug tracking, advertising, behavior tracking.

    Is there evidence that even when you disable telemetry in Firefox it still reports telemetry? That seems like a strong claim for Firefox.

  • It’s not generally a hardware problem. It’s a resourcing problem. Companies like GitHub will have complex software and architecture. IPv6 requires them to get a pool of IP addresses, come up with an IP address management strategy, make sure all hosts have IPv6 addresses meaning that now provisioning systems and tooling to management DNS has to plumb IPv6 addresses through too.

    Then the software stack has to support it. Maybe their fraud detection or auditing systems have to now support IPv6 which means changes to API schemas.

    None of this is a good reason why they shouldn’t do it, but I’ve had to make similar decisions at my job as a software engineer on what looks to be simple but actually requires changes across systems.

  • If I create a secondary config as you are suggesting, wouldn’t it create a conflict with the server blocks of default.conf

    No, you can have multiple server blocks with the same listen directive. They just need to differ by their server_name and only one server block can contain default_server; Reference

    NGINX will use the server_name directives to differentiate the different backend services. This is a class virtual host configuration model.

  • chaospatterns@lemmy.worldtoSelfhosted@lemmy.worldDefeated by NGINX
    1 year ago

    There was an uncaught exception to boot gunicorn workers

    That’s odd that it didn’t cause the Docker container to immediately exit.

    What now? So now that it looks like everything is working. What is the best practice for the nginx.conf? Leave it all in /etc/nginx/nginx.conf (with user as root), reestablish the out box nginx.conf and /etc/nginx/conf.d/default.conf

    My suggestion would be to create /etc/nginx/conf.d/mycooldjangoapp.conf. Compared to conf.d/default.conf, this is more intuitive if you start hosting multiple apps. Keep it out of the nginx.conf because apt-get or other package managers will usually patch that with new version changes and again it gets confusing if you have multiple apps.