Is there improved guidance on migrating from tmux to zellij?
I've attempted to move over a few times, and while this is certainly user skill, it just felt too different from screen/tmux. Perhaps I should bite the bullet and force myself to get used to a new paradigm...
I was confused by its plugins. Despite reading docs over a few days I still have no idea what does runtime for plugins look like, does zellij download them once? on each server start? on each plugin call? and since some features like a switching to a session from another session without spawning child zellij process is available only as plugin, that adds up the confusion, like am I hitting github every time when I switch sessions?
I didn't manage to find a way to update existing session layout when the layout config changed, only to recreate it, which is super boresome when you tinkering with plugin config that is embedded in layout config.
Resurrected sessions needs to be restored manually via somewhat lagging session manager, there's no cli api for that, in general when you need something to be done in another session, you can't.
The only good built-in feature I found is stacking layout showing running command in pane, but I delegate it to tabs in niri now.
Overall I would say if you're long time tmux user, switching to zellij isn't worth it. If you're new to concept of terminal emulators, zellij is much more friendlier, and I'm sure plugins would mature, docs would improve.
For something as simple as a terminal multiplexer, if you aren't seeing immediate value in a switch maybe its fine if you stick with what you have. You don't always need to be on the newest thing. I prefer zellij over tmux, but it is evolutionary not revolutionary. Instead of forcing yourself, save the effort and focus on something more valuable.
Piece of UX feedback for the product team behind Updog: company logos are not searchable. It should be easy to Ctrl-F and find a relevant cloud on that detector, instead of scrolling alphabetically.
You all should add EC2 - extra bonus if you have some way of tracking performance in addition to errors (right now we're seeing EC2 instances in us-east-1c not transition out of Pending status).
I've run a business in this space since 2021, I am yet to meet a business that lets their marketing team own their status page.
You'll find most engineering teams will start owning a status page to centralise updates to their stakeholders, before eventually growing into the customer success/support org owning it to minimise support tickets during incidents.
I'd posit this is more knowing your user. Lots of photo editors/multimedia types use Macs, so it would only help GIMP if they offered Mac keybinds out of the box, or even mimicked the keybinds Adobe Photoshop has.
Loki by Grafana Labs is nice (https://grafana.com/oss/loki/). There was a time (3+ years ago) where the product was changing pretty rapidly and much of the documentation was on git, so we had a few headaches doing minor version bumps, but I believe its much more mature now.
- It is non-trivial to setup and operate. It requires properly configuring and orchestrating numerous components - distributor, ingestor, querier, query frontend, compactor, consul, ruler, memcache, index service, etc. - see https://grafana.com/docs/loki/latest/get-started/architectur...
- Its' configs tend to break with every new release, since some configs become obsolete and some configs change names and/or structure.
- It is very slow on "needle in the haystack" queries such as "search for logs containing some rarely seen trace_id", since it needs to read, unpack and scan all the logs at object storage. This may be also very expensive if the object storage service charges for read IO.
- It doesn't support log fields with big number of unique values (aka high-cardinality log fields). It you'll try storing logs with high-cardinality fields into Loki, then it will quickly explode with enormous RAM usage. Recent Loki releases provide half-baked solution for this problem - "structured metadata" ( https://grafana.com/docs/loki/latest/get-started/labels/stru... ), but it is still experimental and requires non-trivial configs (aka it doesn't work).
I am teaching myself some more full-stack dev and try out AI assisted coding, I decided to build Terminal Tinder, a way for your machine to learn what colorschemes you like, and maybe generate some novel ones for you.
Would love for people to try it out and hopefully find some fun or use out of it!
You solve a lot of the same problems that other tech companies solve, just with different constraints. An example I like to use is: "Facebook can afford to lose a 'like' on a post -- whether that is through data loss or just eventual consistency -- while we cannot afford to lose a penny (exaggerating a bit here) since there are people making live decisions on that penny"
Those sort of problems are more on the product side, along with the regular slew of product development tech problems. On the infrastructure/platform side (where I work) it is remarkably close to "regular tech". Same types of distributed systems problems, database issues, CI/CD pipelines, engineering efficiency, etc. The "new" part here is working with the finance specific areas such as physical data centers and networking to clients, or domain specific items such as data retention for compliance.
The firm I work at developed an internal library (open source soon hopefully!) that does all our templating in Python, example:
import os
"""
Imports redacted, but this imports our library
"""
NAME = "my_app"
PORT = 5000
DEPLOY_ENV = os.environ["DEPLOY_ENV"]
deploy_all(
create_stateful_service(
NAME, http_port=PORT, cpu=2000, memory=500
),
create_ingress(
NAME,
service_name=NAME,
service_port=PORT,
hostnames=["myapp.internal.com"],
),
)
In the background, this converts a bunch of objects to YAML, leveraging the fact that objects in Python are just dictionaries. It then takes these objects and sends them to the K8S API. Really improved our DevEx since you can do complex tasks like "define a deployment, deploy it, and then check server status" because it is all just Python at the end of the day.
I was tinkering with a similar approach to this, using Python objects to generate the YAML. I'm not working in it right now, but I'd love to see other tools use this approach.
It should be like that from the very beginning, any and all configuration management systems that chose YAML as base instead of DSL (even if DSL is just a subset of Python or Lua) have same problems.
