• 1 Post
  • 59 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle


  • That basic idea is roughly how compression works in general. Think zip, tar, etc. files. Identify snippets of highly used byte sequences and create a “map of where each sequence is used. These methods work great on simple types of data like text files where there’s a lot of repetition. Photos have a lot more randomness and tend not to compress as well. At least not so simply.

    You could apply the same methods to multiple image files but I think you’ll run into the same challenge. They won’t compress very well. So you’d have to come up with a more nuanced strategy. It’s a fascinating idea that’s worth exploring. But you’re definitely in the realm of advanced algorithms, file formats, and storage devices.

    That’s apparently my long response for “the other responses are right”



  • A complicated plugin ecosystem (e.g. Jenkins) makes for a terrible use experience. It’s annoying to configure a bunch of config files. Managing dependencies can be a complete nightmare. these problems also complicate your ci/cd.

    So I’ll offer a slightly different answer. I prefer a single file instead of splitting up the config. And I’ll use OpenTelemetry as an excellent example of why. the plugins are compiled right into the app binary. This offers a ton of advantages, including a great reason to merge all of your app configs in a single file.

    This really only works well if you have a good app though.






  • Professionally, I’ve spent the last year almost entirely focused on o11y, a numeronym for observability. IMO you want to run opentelemetry (aka otel) for a lot of this stuff. It’s a fantastic tool. We tell clients that if they don’t use otel, then they’re probably doing o11y wrong.

    You can run it as a collector to scrape log files. If your apps are instrumented, they can emit telemetry via OTLP to otel instead. Then otel can process and export the data to various data backends like Minor (metrics), Loki (logs), and Tempo (traces). Then use Grafana for a UI. That particular set of tools is known as the LGTM stack. if you only want to handle logs, your stack could be simpler: otel, Loki, and Grafana.

    A final thought is about a seeming want for metrics generated from logs. Otel can do that for you too.


  • Well that’s an interesting take! What aspects are you opposed to?

    IANAL but I did read through the patents agreement that you linked. It basically says do whatever you want with Go as long as it different infringe on Google patents. Which is pretty much backed by US law anyways and I assume other countries as well. The sketchy part is that your license is revoked as soon as they file a lawsuit rather than win it. Honestly, I’d be surprised if Google ever used this in a legal dispute because there would be a huge community backlash.

    That also only applies to Go developers. You would only be a user for a tool written on Go. How does your using a tool written in Go translate to support for Google and its bad practices? Do you not use any software written in Go?

    Sorry if this is sounding argumentative! I’m generally a big fan of Go and definitely opposed to Google and using its products. This is a topic that I haven’t considered before so my questions represent my sincere curiosity.



  • Lodra@programming.devtoSelfhosted@lemmy.worldBest way to dockerize a static website?
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    8 months ago

    The simplest way is certainly to use a hosted service like GitHub Pages. These make it so easy to create static websites.

    If you’re not flexible on that detail, then I next recommend Go actually. You could write a tiny web server and embed the static files into the app at build time. In the end, you’d have a single binary that acts as a web server and has your content. Super easy to dockerize.

    Things like authentication will complicate the app over time. If you need extra features like this, then I recommend using common tools like nginx as suggested by others.





  • First is complexity. A simple helm chart works great but more elaborate charts can turn into a maintenance problem. This is especially when managing a large number of apps and need to establish and maintain standards across them. E.g. you want to add a new label to every helm chart you use. You now get to making 60 PRs for 60 charts. Or you can tie them all together with chart dependencies. This can be done well but almost never is. It’s just too easy to build a bad helm chart. Kustomize allows you to do this from a “top-down” perspective

    Second is modifications. Consider as an example that you want to run filebeat as a sidecar container on some pod to capture its logs. But the helm chart you’re using doesn’t include this feature. You have two choices: modify the pod when it’s created with a mutatingwebhook or similar (super complicated solution) or you can copy/fork the chart, add the functionality, and maintain it going forward. Kustomize just doesn’t have this problem. You can just modify a base manifest with overlays.

    Last is the nature of Go templates which helm charts are based on. Everything outside of {{ }} is just plaintext. This leads to a ton of limitations. Got a whitespace issue? You’ll probably find out at runtime. Want your IDE to identify syntax issues, provide, intellisense, etc. on the final manifest? Good luck! You need to render that chart first. With Kustomize, every manifest is structured text (yaml). So you get the benefits of all standard tooling for yaml data in your IDEs and CI/CD pipelines.

    Honestly, I could keep going (helm releases ugghhhh!). But helm definitely wins on one point and it’s a big one; Helm is the standard for distributing k8s manifests. So every meaningful project supplies helm charts. Kustomize doesn’t even come close on this one. That said, I think Kustomize manifests are just simpler to build. So having an official base manifest for every project just doesn’t matter too much.