It seems like the main selling point is going to be performance over tmux(or really any multiplexer) with the anticipation of giant multiplexer sessions resulting from increased AI agent usage(which is talked about in this video https://www.youtube.com/watch?v=T5gV6anSt-4).
I'm fairly new to using multiplexers and not a hardcore user as I'm mostly getting my feet wet with herdr at the moment. For the hardcore users, is performance really a bottleneck? How big are your sessions that you have rendering issues?
Regardless, whenever Mitchell talks, I'm interested so I'm signed up for the release notification and will definitely check it out!
With the recent videos, I think there are multiple selling points.
* General performance.
* Run the server and client everywhere. There are already multiple libghostty clients for mobile. Native terminal support on mobile is great, especially for coding agents.
* Native sessions. The lack of sessions in terminals is part of the reason why some people went with tmux in the first place.
* Multiplexer performance isn’t noticeable until you start running multiple sessions with multiple agents. Sometimes half of my RAM ends up being allocated to Ghostty/Alacritty + tmux.
* As for rendering, performance is one thing. But the multiplexer tax is really, really annoying. For example, some features are available in Ghostty but not tmux, and vice versa. It’s the little things that pile up.
Another point is that, for some reason, multiplexers and terminals often diverge in terms of feature implementation. Probably because one traditionally focuses more on remote workflows, while the other focuses on local workflows. With AI, though, it makes a lot more sense to have both. Running long-lived sessions with agents is becoming normal, so the line between those use cases is getting thinner. That’s probably why they’re focusing on this approach.
That's a pretty narrow viewpoint. I could see many examples where it's better to work than focus on your kids... At least for society. Leader of a country comes to mind as one of those jobs
If you think about this in terms of systems... it's unsustainable. You'll eventually get to a point where the damage you've done requires a flow of wealth/energy that cannot be generated for everyone.
I'm assuming that we can drive our environment to that kind of state, maybe there's an upper limit on how bad the environment can get. I'm not a climate scientist and don't have the curiosity to look into if there's a limit to climate change.
Imagine bushwhacking your way through a bunch of conflicts while rebasing on main... Now you realized that you needed to do some other work before your pr is ready for review... Now you need to rebase on main again and get to relive conflict hell again.
Maybe I'm one of the stupid incompetent people referred to in this post but I haven't figured out a way to deal with the having to solve the same merge conflicts when I rebase again :(
And here I am pooping out simple typescript... These articles always make me feel like I'm wasting my talents working on products that don't really have the need to leverage any understanding of what's happening under the hood at the CPU instructions level.
Maybe I'm too stupid to understand the article... How does this achieve performant querying for olap and oltp purposes?
Based on my understanding, olap queries will go to the parquet files which are stored in a columnar fashion and oltp style queries will go to a caching layer that sits on top of those parquet files?
What's the special sauce here? Seems like they're just caching the data which, for all intents and purposes, seems like the same solution of storing another copy of the data which is what they say they're avoiding.
Hi, I work on Lakebase (but not on storage), here's how I understand it.
For Lakebase and Neon, our architecture needs the caching layer regardless (what we call Pageservers). Performing reads from S3 directly is too slow so we reconstruct pages and keep them on an nvme server for faster querying. Changing the format on S3 to be Parquet effectively introduces no additional copies over our existing architecture
Hmm, if the caching layer doesn't change(I assume it was optimized for olap style queries), and the new parquet format is better for olap... I'm still not understanding how it performs well for oltp reads.
I'll give the article another read... Maybe I missed something. Thank you for the response! Really nice to be able to get info straight from people who work on the product
I assume the parquet files are way larger than the page format, doesn't this cause a lot of read amplification? OLTP side needs to read a lot more data to fetch a single old row that's stored in parquet format.
one of the benefits of being on android and being able to sideload apps. Look up "revanced youtube" and you'll be able to turn off shorts.
ublock origin for blocking them on desktop. If you're on an iphone... uninstall youtube?
my quality of life has increased substantially... although sometimes the app bugs out and shorts still make it on my home page. I spend like 10 minutes scrolling through shorts and get a weird shock "how the fuck did I end up here?", restart the app and boom shorts gone again.
reply