If you’d like to learn more about Haptic, why it’s being built, what its goals are and how it differs from all the other markdown editors out there, you can read more about it here.

As others have noted, the app doesn’t work on mobile yet. Anybody willing to share the content here for mobile users?

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”

deleted by creator

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.

For debugging across disparate app, hosts, etc.,x I think the best current option is spans and traces. If you aren’t already familiar, look into general observability, logs/metrics/traces, and definitely opentelemetry!

I certainly don’t have an answer for you. Sorry 🙂

I’m super curious about your motives and goals though. Why do you want to do this??

This is an especially tragic case. IMO, Gitea has one of the best names in software.

I recently discovered k3d. It’s a light wrapper around k3s, which is kubernetes on docker. It’s amazingly easy to use! If you have docker installed, you can learn the commands and create a k8s cluster in under 5 minutes.

For anyone like me that likes k8s, k3d is a fantastic alternative to docker compose!

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.

The admins just launched a bunch of new services, including Blocks. I’m not sure if it checks all of your boxes. But it’s an obvious choice to look into

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.

I can agree that crisp, cold air has a taste sometimes. But I would never describe it as milky. To be fair, I’m not sure how to describe sooo

The CEO now seeks help from Phutar Afrayughum, a psychic and extrasensory perception specialist who allegedly helped Google increase their marketshare in the messaging app market, and was also involved in developing the Material Design framework.

Seems like a legit article :shrug:

OpenTelemetry

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.

I started using git meaningfully about 10 years ago. Mercurial maybe 6 years ago but not very much. And I was not a fan. Especially how it tracks things recursively.

So honest question. Why?

This is excellent. I may copy the rough format for tracking things internally at my company!

Btw, I agree with most of your decisions in here with just a few exceptions.

• kustomize > helm
• Argo > flux

My last thought is less clear though. There are good observability solutions besides datadog. Grafana Cloud is great. Honeycomb has a similar offering. But all are pretty expensive though.

If you aren’t using OpenTelemetry, you’re probably doing observability wrong!

Disclaimer: I don’t yet understand why this is valuable.

I looked through the yaml example a bit. It looks pretty rough. This really makes familiar and readable yaml into much longer configuration. It’s much harder to read. First impression is a pass.

The Primeagen has a great reaction to dreamberd. Enjoy!

https://m.youtube.com/watch?v=tDexugp8EmM