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








  • So I read a bit of Mozilla’s documentation about this feature. It sounds like they’re trying to replace the current practices with something safer. Honestly, my first thought is that this is a good thing for two reasons.

    • It’s an attempt to replace cross site tracking methods, which are terrible
    • Those of us that fight against ads, tracking, etc. can simple use typical methods to block the api. Methods that were already using (I think)

    If both of these are true, then it could be a net positive for the world. Please tell me if I’m wrong!




  • 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.