Ghostty terminal is out!
(github.com)
from TheTwelveYearOld@lemmy.world to linux@lemmy.ml on 26 Dec 20:59
https://lemmy.world/post/23575655
from TheTwelveYearOld@lemmy.world to linux@lemmy.ml on 26 Dec 20:59
https://lemmy.world/post/23575655
threaded - newest
thanks but i’m good with st
rn Im using Kitty, I’ll check out Ghostty later.
I <3 kitty, will probably give this a look but I’ve got kitty so well tuned to my liking at this point it’s hard for me to imagine switching
Have got kitty and xterm looking identical, multiplexing is done by zellij anyway
I think kitty is a bit snappier but honestly you could switch one out for the other and I probably wouldn’t notice
I think I’ll stick to alacritty, but options are always fun
Same. Wezterm is good enough so far
I was very satisfied with Bash for a long time until my friend got me using Zsh. I still am not sure i need Zsh over Bash honestly. Command autocomplete is obnoxious
I don’t know that anyone “needs” anything more than bash. It’s the creature comforts that sell the other shells. That said, bash has never hung or crashed on me. I can’t say the same for zsh.
Bash and zsh aren’t terminals. They’re shells.
Different things. Bash/Zsh/Fish/Nu are shells, i.e. a low level CLI interface with the computer. On systems with graphics you need a graphical program to display the shell, e.g Konsole/Gnome-shell/Alacritty. Also there’s a third (optional) program to render the line where you type commands differently, this is called a prompt and there are several different ones, e.g. Powerlevel10k/oh-my-posh/Starship.
I’ve been a
footuser for quite some time now. However, this seems interesting.IME it feels much snappier than foot.
What are the differences between all of these terminals?
ikr, i try to stay away from the stock one too
If you’re occasionally using them, there aren’t any.
If you’re excessively using them, there are many.
Could you highlight a couple, I’m kinda in between with my terminal usage…
Sure, I can do that.
storurxvt. These are Xorg-only.xfce4-terminalis the middle ground for lightweight and feature-rich. If you are on KDE,konsolewould suffice. You can use these on Xorg and Wayland.terminatoris your friend. Used this on Xorg but not sure about its Wayland compatibility.kittyandalacrittyis out there. Both should work on Xorg and Wayland.footis the best lightweight terminal emulator. My current personal favourite.Fucking legend!
Pretty sure I’m using konsole right now, whatever it is, it came pre-installed on my distro.
Might check out foot and kitty, what I’m using is working right now, but always nice to look into different options.
Yeah, it’s one of the greatest characteristics of FOSS. We have many options and endless posibilities.
Glad to help.
Hacker news users seem happy with its performance, so will try tomorrow. Fun with new terminals.
Is there a difference in performance between terminals? Holy hell
Edit: i always used byobu btw
Cool project and… no screenshots? 😭
Every. Damn. Time.
Lol right?
I mean, it’s a terminal emulator; what’s it supposed to show, a bunch of white text on black background?
It supposedly supports fancy features, so I’m curious to see how those look, they also say it’s got top of the line speed, so maybe a screencast with side by side of reference terminal emulator (xterm?) and ghostty displaying heavy throughput output to see the smoothness goodness
A screencast cannot really capture that. Practically any terminal is fast enough to render a shitton of text quickly and “smoothly”.
The difference in speed can only really be felt.
W.r.t. UI, it looks exactly like you’d expect a GTK4/adwaita terminal emulator to look.
By “can only be felt” do you mean in the way it affects the performance of your system?
No terminal emulator ever should affect the performance of the rest of your system.
I mean that totally w.r.t. how it feels to interact with the terminal emulator.
Sorry, what does w.r.t. stand for?
No idea honestly, people are saying that certain heavy output programs might just slow down the execution of other graphics related processes because text is usually expensive to draw, haven’t tried it myself
with regard/respect to
Whoever told you text is expensive to draw has no idea what they’re talking about.
Hey OP, what is the coolest feature?
It’s awesome to see a project written with Zig!
They know what they doin. Take off every zig.
And now that song is back in my head. Thanks man :|
I must be retarded. People are excited about a terminal emulator. Why?
It’s incredibly fast, has the features you would want like tabs/splits, maintains comprehensive compatibility, and is written cleanly in Zig. What’s not to like?
I’ve never seen a slow terminal emulator. Most terminals have tabs and splits. Never experienced compatibility issues. Don’t care about Zig at all.
Are these all the reasons? Another toy software written out of boredom.
Yeah, I couldn’t care less what language its written in
Most terminal emulators are in fact slow and they can be a huge bottleneck if you run complex TUIs or workloads that print a lot of output.
Ever written a program that was extremely slow only for it to run instantly after removing your debug print statements? That’s because your terminal is slow.
Fast terminal emulators already exist, but they notably refused to add tabs/splits and overall tended to be quite janky. Ghostty merging these features may not be the most groundbreaking innovation, but a high quality piece of software that can drop-in replace something you use daily with some cool improvements is something to be excited about to me. :-)
Thanks, this clears things up. I didn’t know what exactly was making print IO slow.
I don’t use any complex TUIs. Pretty much everything is CLI or GUI. Which TUIs did you have in mind that were slow?
I’d like to test this soon. I’ll look for a modern TUI framework.
On slow terminals k9s can be rather sluggish when scrolling through the lists
Fair. I hate kube though. Most companies run just 10 pods because they cargo cult google. The complexity of it is completely unjustified
The right tool for the right job.
I agree that many small businesses jump to Kube too early. If your entire app is a monolith and maybe a few supplementary services, then Kube is massive overkill.
But many people also tend to overlook all of the other benefits that suddenly become very easy to add when you already have Kube, such as a common way to collect logs and metrics, injecting instrumentation, autoscaling, automated certificate handling, automated DNS management, encrypting internal network traffic, deployment tools that practically works out of the box, and of course immutable declarative deployments.
Of course you can build all of this yourself, when you need it, but once you have the foundation up and running, it becomes quite easy to just add a helm chart and suddenly have a new capability.
In my opinion, when the company it big enough to need a dedicated ops team, then it’s big enough to benefit from Kube.
Something like heroku is better for out of the box stuff like logging and autoscaling. Some companies like banks have to have their own data center. But they should write their own “tools”.
Must be fun looking at 10 pods and pretending to be in control of Google search by proxy. Autists have a peculiar way of day dreaming, as they’re extremely limited in imagination. They always seek artificial complications to cover up the fact that what they’re doing is actually not far from trivial, and without gatekeeping a school kid would be capable of doing.
I’m not quite sure what you are getting at… Are you implying that I’m autistic because I only have 10 pods in a Kubernetes cluster?
Presently our clusters run roughly 1400 pods, and at this scale there certainly are benefits to using something like Kubernetes.
If your project is small enough to make sense on Heroku, then that’s awesome, but at some point Heroku stops making sense… both for managing at scale, and costs. Heroku already seems to be 2-4x as expensive as AWS on-demand. Presently we’re investigating moving out of AWS and into a datacenter, as it seems that we can reduce our costs by at least an order of magnitude.
No. I didn’t mean to attack you in particular in any way. I apologize if it came off as such. I just dislike the blind copying of what Google and Facebook do. Docker is another atrocity that everyone seems to feel obligated to use.
Heroku supports moderately large amounts of requests. It’s less expensive than having a proper sysops team in most cases.
With 1,400 it’s probably worth it to move away from AWS. Something like self-hosted Triton (descendant of Solaris) cluster would be far more elegant than kube and lxc.
Apology accepted, and thank you for not name calling.
And yeah, if you can save the ops team salaries by picking Heroku, then it certainly might offset the costs.
When you talk about Triton, do you mean this? Because funnily enough one of their bigger features seems to be that you can run Kubernetes on top of it. It looks pretty cool though, but I must say it was quite hard to find proper info on it.
Triton also seem to push for containerization quite heavily, and especially Docker… So when you talk about Triton are you suggesting to use the Infrastructure Containers or Virtual Machines instead?
Triton and SmartOS are still Sun Microsystems people. Solaris zones preceded Linux containers by almost a decade. They lost the popularity contest, so they have to provide compatibility with kube and docker. I think infrastructure containers are zones with extra whistles.
For even better performance, I’d go with Xen and Linux unikernel. The startup time can be just 1s with such minimum overhead. It also greatly reduces the attack surface. I highly doubt you’ll be allowed for such a drastic change though.
My team is constantly looking for new technologies to make sure we’re not turning ourselves into dinosaurs. We all know that Kubernetes won’t last forever, something better will come along some day.
That being said I don’t really see the full value of Triton or Xen with unikernels… They might have a bit less performance overhead if used correctly, but then again Kubernetes on bare metal also has very little overhead.
Kubernetes is certainly comes with a learning curve, and you need to know how to manage it, but once you have Kubernetes there’s a ton of nifty benefits that appear due to the thriving community.
Need to autoscale based on some kind of queue? Just install the Keda helm chart
Running in the cloud and want the cluster to autoscale the nodes? Just install cluster-autoscaler helm chart
Want to pick up all of your logs and ship them somewhere? Just install the promtail helm chart
Need a deployment tool? Just install the ArgoCD helm chart
Need your secrets injected from some secret management solution? Just install the external-secrets helm chart
Need to vulnerability scan all the images you are using in your cluster? Just install the trivy-operator helm chart
Need a full monitoring stack? Just install the kube-prometheus-stack helm chart
Need a logging solution? Just install the loki helm chart
Need certificates? Just install the cert-manager helm chart
The true benefit of Kubernetes isn’t Kubernetes itself, but all the it’s and pieces the community has made to add value to Kubernetes.
That’s what I meant. It’s a standard, and the sunk cost and network effect make it practical. Same as HTTP and SSL compared to SCTP and IPSec. Isn’t it sad when you see web devs preferring native apps even more than the general public?
Packaging is very practical, but that’s a boring dead end that unfortunately lasted 20+ years. I mentioned Triton in the context of Sun folks who have done containers better and earlier, yet failed to market because Sun went bankrupt. Your long list that was packaged is nothing that can’t be developed in-house better with far less complexity. Triton provides no benefit to you, but who knows maybe you’ll need dtrace one day.
Unikernels and Xen allow function as a service (I assume you don’t need that as well). FaaS is the future, as it’s a progression of the micro services trend. Startup time and hardening are not of interest to you as well, so no reason to switch.
I’m not completely against packaging. It’s great for open source desktop apps. When it’s out of sight away from the user, it turns into a boring game.
feddit.uk/comment/14184961
Most for wayland have no tabs.
Why is it so funny to see issues with a terminal running in 4k? It never crossed my mind that some folks do that.
Konsole has no tabs?
Beats me.
Konsole has all the KDE dependencies.
So? You’re limited by disk space?
People gets excited to see something written in their favourite niche language.
I actually like Zig. I wish something like CUDA was available in it.
It’s ridiculous how much time people are spending performance optimizing terminals.
xterm on a 120MHz Pentium on X11 in the 90s performed “fine”.
Assuming you had a pretty decent monitor and graphics output in the 90s, it may have been 800x600, but more likely 640x480, and you’d have been using the standard issue bitmap font with no anti-aliasing, blitted to screen using software rendering. Probably in a single colour, too.
Alas, the problem with that is that it doesn’t scale. On xterm a 4K monitor, I can watch Vim redrawing the screen, paging through logs is painful. Use Kitty for the same, it’s instant, I can flip through tabs and split screens too, and have niceties like anti-aliased fonts and transparency if I want them.
Some people spend a lot of time in the terminal, so I can’t fault them for taking the time to make a nice working environment and sharing that work with others.
“decent” hardware back then ran at 1024x768. I never ran less. And definitely multiple colors. But sure - no anti-aliasing and other features. But also on hardware several orders of magnitude slower.
Though granted I don’t have a 4k monitor so maybe there are issues with that…
I mean - it’s the first thing I open… Which is why I’m surprised others seem to have “performance issues” since I’ve never seen any.
The “Abandon all hope, ye who enter here” terminal?
Edit: that was once a comment in the sourcecode.
Hah! It’s funny I just fired it up again for the first time and I do see a bit of flicker in xterm when paging full-screened in vim… So maybe there is something to performance optimizing terminals. :-)
Every Linux user has the earliest and lowest specced version of the 4k Lenovo thinkpad from back when 4k on a laptop was impractical and a stupid idea.
The problem with xterm is that everything else about it sucks. The only other half-decent performer is mlterm which is decent but has its share of issues.
This one feels quite snappy; better than foot.
Sure, it performed “fine”.
But it was sluggish compared to the VGA ttys we were used to.
Now, if we can have something as snappy and at the same time as pretty as Eterm… 👌
But does it roll down like Yakuake did before I updated Fedora and broke it? :( That’s all I want.
Yes, it calls that its “quick terminal” feature
Okay, I’m sold.
I can’t get it to work on Linux and on the website it is only stated under MacOs features…
Aw, didn’t know that! Maybe make an issue? Yakuake works under Wayland, so there’s nothing that should stop them
Hm… I don’t see it stating anything about wayland, but since it says “native” in some many places, I need to assume it won’t use Xwayland, unless specifically told to.
Right? Anyone to confirm?
i dont have xwayland, and it worked (though i did not test enough(lack of interest))
It works natively on Wayland. The UI uses gtk4.
Hm. That’s good. I wonder if it could be compiled to use no toolkit, but only rely on server-side decos.
Oh well. I’ll give it a try.
EDIT: We’ll it, indeed, can be compiled without toolkit. Nice. Strangely it defaulted to US keyboard layout. While all other programs do respect my system keyboard layout setting.
Any speed comparison?
Looking at ghostty-git in AUR, zig is built on haskell? With 221 haskell libraries.
And what does it need pandoc-cli and hslua-cli for?
Checked the build.zig file for ghostty, seems to be for manpage generation. Zig itself doesn’t use Haskell though
What the hell?
Chill, it’s just pandoc.
But i use pandoc-bin, because i was annoyed by dozens of haskell lib updates each update run…
Unless you frequently build this from source, you don’t need to care about the pandoc build-time dep.
Looked at it, interesting, no package, installed
cosmic-terminsteadUses alacritty under the hood, with tabs and tiles!
Thought out choice but disappointing nevertheless:
What do you think about the Kitty Graphics Protocol?
I like Kitty Graphics. I like graphics in the terminal for two reasons:
Reason (1.) works with Kitty. (2.) does not. (2.) is pretty esoteric so I think sixel will probably die out soon due to the user base?
I get that Sixel is old AF but is there a new standard or is it just an open sea of fragmentation where everybody picks some branched attempt at doing the same thing and rolls with it instead?
Kitty Graphics Protocol seems to be the new one they’re pushing
For those that are, for some reason, incredulous of having more performant software (???), here’s a simple program to demonstrate the point:
use std::{ fs::File, io::{BufWriter, Write}, }; fn main() { let buf = File::create("/dev/stdout").unwrap(); let mut w = BufWriter::new(buf); let mut i = 0; while i <= 100000 { writeln!(&mut w, "{}", i).unwrap(); i += 1; } }It simply prints the numbers 0-100000 to the screen. Compile it (
rustc path-to-file). Run it in a non-accelerated terminal withtime ./path-to-bin. Now time that same binary in a terminal emulator with GPU-acceleration.The difference becomes more apparent with more text. Now, imagine needing to use something like
findon a large set of files. Doing this on a non-accelerated terminal is literally slower.It’s fine if you don’t need a GPU-accelerated terminal, but having acceleration is genuinely useful and a noticeable quality-of-life improvement if you do anything more than just basic CLI usage.
Isn’t the terminal only going to affect performance when it’s displayed in stdout? I’d think a program like find / using pipes would send the data under the hood and all that the terminal would deal with would be the output of the entire command.
Perhaps that’s true. Although, I think that should be tested because I’m a little unsure since pipes are just the stdout of one command being used as the stdin of the following command. There’s still some output, even if you don’t see it.
In any case,
findhas many uses, many of which will print data to the screen, andfindis far from the only use case in which this would be apparent. There are tons of situations in which you’re going to have to work with large amounts of stdout/stderr, and having a GPU-accelerated terminal will be much faster in all of those situations.warning: this is a giant rant lol
Before the rest of my comment, let me be clear, I think this terminal is good, and i have no problems with it. My problem is with the hype.
I simply don’t understand the hype whatsoever. First of all, it’s not even faster than my current terminal. especially when running
cat /dev/randomfor whatever reasonFor the test i ran this rust program i saw in a comment thread somewhere
use std::{ fs::File, io::{BufWriter, Write}, }; fn main() { let buf = File::create("/dev/stdout").unwrap(); let mut w = BufWriter::new(buf); let mut i = 0; while i <= 100000 { writeln!(&mut w, "{}", i).unwrap(); i += 1; } }compile with
rustcto test yourself.running the binary with
hyperfine, i get~35mson my current terminal (foot), and~40mson ghostty.The terminal window sizes about the same size, in fact, there were 3 extra lines in
footso it was technically handicapped.Next is the whole “native ui thing”, which sure, if you use gnome, or mac is fine i guess, but what about kde where qt is used. And for me i simply hate title bars so i turned it off immediately and now it looks better.
I do think the tabs are cool, not much to say about that, I wouldn’t use them, but for those who do, pretty cool.
I have a similar opinion with the panes, personally i think if you want panes, just use a tiling window manager, or tmux or something, but i also dont really have a problem with this (tmux can be annoying).
If I’ve missed anything let me know, because I really dont get it.