fast-data-dev VS contour

I liked https://lenses.io/ Lots of capabilities but it's not free as I know.

Lenses

For Kafka Dev I use https://github.com/lensesio/fast-data-dev

Currently I'm using Lenses:https://lenses.io/ as UI tool, but while turning on kafka-start-server server.properties and launch the UI on localhost, it failed to connect:

Oh thats sad to hear ... lenses.io is so powerful I am not sure how I would have gotten by to this point without it!

In Addition to the more critical replys from others, why Kafka still makes sense imo: - you could organist everything with custom pipeline/services at your scale. The cost of maintaining those and keep the technology up to date is growing exponentially with every new Service. Kafka offers ansinge Plattform with a couple components which need to be kept up to date. - deploying, managing and monitoring those service is also a big task and does not come for free. - unless your using Kubernetes underneath, scaling is not easy with services. - peer to peer communications of microservices should be avoided because your building a „deathstar“-like architecture where everything is linked and effectively you’ll end up with a distributed monolith. A message broker or message queue helps to avoid this, Kafka is a good tool for that. - I heard that those aws Kafka replacements are not 100% Kafka as one might expect, you should be careful there. But confluent or other providers probably offer hosted solutions on aws too. - https://lenses.io/ helped us a lot when we started with Kafka to see how everything works together, create stream processor’s with sql and easily deploy Kafka connect workers. The tool costs money though but is worth it in the end in my opinion. (Disclaimer: I don’t work for confluent or lenses, we’re running open source Kafka with strimzi and lenses)

https://github.com/lensesio/fast-data-dev is a really cool option for a Kafka development environment based on docker and/or kubernetes.

Yes: - https://lenses.io/ (use the Lenses box, it’s free) - https://github.com/lensesio/fast-data-dev - https://github.com/provectus/kafka-ui

Another problem is that the cursor moves while the screen is buffer is being rendered. The location is only really known once the cursor settles in the same place for some time, which is unacceptable in terms of latency.

The synchronized output extension could be used to do this, though. https://github.com/contour-terminal/contour/blob/master/docs...

https://github.com/contour-terminal/contour/issues/382

This apparently does not support the Kitty graphics protocol, just Sixel, which makes it look fairly unattractive to me, personally.

contour - https://github.com/contour-terminal/contour. https://github.com/contour-terminal/contour/issues/100 and other modern unicode focused attempts to update the terminal world

contour : a terminal application

https://github.com/contour-terminal/contour Contour has a implementation for this. See this release: https://github.com/contour-terminal/contour/releases/tag/v0.3.6.240

Now that I'm well rested I decided to compile some similar terminal emulators with clang++ and rustc to see how big of a gap we're looking at. For the C++ terminal emulator I compiled contour with ~80k lines of C++ and over 200k lines when accounting for dependencies (not including dynamically linked dependencies), and then I'm using alacritty with ~35k lines of Rust and over 2 million (!) lines for the whole dependency tree when vendoring all dependencies. Because Rust tries to make most software cross platform with conditional compilation and many of these aren't Linux specific libraries I'm gonna assume it's compiling half or two thirds of the lines of dependencies for this experiment with the C++ compiling probably 3/4ths of the dependency tree considering I'm not on windows.

I have my eyes on this though.