904 karma · joined July 25, 2017
The transform processor could be useful if they ever deprecate the resource_to_telemetry_conversion flag, but its still a pain point because it hinders a developers autonomy, and requires a whitelist of labels to be maintained on the collectors by another team.
They maybe trying to address label cardinality but their approach seems like they are throwing the baby out with the bath water. The developer experience suffers as a result because from a dev pov, resource attributes are added to the metric yet this relationship isn't transferred when translated to Prometheus metrics.
Luckily the prometheus exporters have a switch to enable this behaviour, but there's talk of removing this functionality because it breaks the spec. If you were to use the OpenTelemetry protocol in to something like Mimir, you don't have the option of enabling that behaviour unless you use prometheus remote write.
Our developers aren't a fan of that.
https://opentelemetry.io/docs/specs/otel/compatibility/prome...
Otherwise they are very similar boards.
Also thank you for reminding me of clear linux.
No GUI, redis, dex, and the various controllers and servers. Flux is very simple and is able to suite my needs.
I don't have specific numbers unfortunately since it was years ago I benchmarked Kine against etcd. But I had a better results with etcd both in cluster and single node.
I happened to stumble upon this paper that echos my experience. https://programming-group.com/assets/pdf/papers/2023_Lightwe... Particularly, the high controller cpu usage (even for an empty cluster), and higher latencies.
* A helm controller is included in k0s
* Etcd is bundled and bootstrapped automatically which I perfer because I dont want the overhead of the translation that Kine does. Although Kine is available for a non-etcd datastore if that is preferred.
* Upgrade controller is included (autopilot).
* They have a local storage provider based on OpenEBS.
* Ingress is missing, but due to the built in helm controller that can be boot strapped upon cluster initialisation.
Overall, together with k0sctl and its declarative configuration it is easier to deploy k0s than it was k3s.
Good progress though and I'll revisit it again soon.
IMO Distroless or even scratch is nice for statically complied binaries or self contained deployments, but if there's a dependency on user space then it becomes complex.
Some setups can be elaborate with Roms listed in Steam / Big Picture with box art, fan art, and various metadata. Software like Steam Rom Manager assist with this.
Considering console emulation is often played with controllers perhaps infront of TV, Steams launcher is probably more suitable for launching emulation than using a keyboard or mouse for a start menu.
https://www.youtube.com/watch?v=CRnrSlL-Oug
Grab some popcorn because its a hell of a ride.