• 2 Posts
  • 66 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle
rss







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






  • I think this is a side effect of sharing and discussion these events online, especially in a link aggregator like Lemmy. You can you see inconsistent views presented in multiple threads yet they feel as if you’re interacting with the same group of people.

    Some people are happy about this turn of events while others are not. I expect that you’re seeing differing major opinions from separate groups of people.


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



  • I only have anecdotal info for based on some reading I did last year. As far as I recall, the program and software are new. So they’re slowly building up features for more complicated tax scenarios an in turn, slowly making it accessible to more of the population.

    It’s just a matter of time before this is widely available. I read the post title as “we succeeded in this first year’s test and plan to continue the program”.



  • Open source software literally means that the source code is available to anyone. In GitHub, that just means that your repo is public rather than private. But your method technically doesn’t matter. You could publish to a forum if you wish. That’s still open source!

    Free OSS just means that anyone is free to use and modify the source code for any purpose. The details are usually defined in a LICENSE file.

    I feel like you’re really asking about the common practices and methods used in FOSS. Right? If so, that’s entirely up to you as the maintainer. As the project matures, you may attract other contributors which will in turn will motivate change to your tools and methods.

    Start with what works for you. Model after similar projects if you wish. Adjust as change is needed.