Live data from Hacker News

Ghostty 1.0

ghostty.org

691–700 of 719 posts

Re: Ghostty 1.0

#691
post #687

Earlier quoted context omitted.

> The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely…

It is very nuanced, but it's important to realize how small the power budget is and how just tens of milliwatt here and there make a huge difference. To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours - you need to stay below 5 watts of battery draw on average , and considering that the machine will likely do some actual computation occasionall…

Well I would be very interested in some of this, but it all seems theoretical and mythical. Seriously, what terminal is giving 20% better battery life (or whatever number that people will notice) than kitty.

How can I observe any of these claims in practice? You’ve put some down some bold claims about how things should be done but no way to verify or validate them at all. Put up with some real power benchmarks or this is just crack pot.

> To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours

I used 12 hours to be nice. The sell of getting another 10 minutes or so out of 20 hours is even more stark.

The cases where you push a line and scroll, you're repainting most of it anyway. The cases where you're not are end up being infrequent enough that optimizing them in the ways suggested makes an unnoticeable impact. Build it and they will come maybe?

> Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts.

In most cases people can get by with an iGPU for a battery laptop cases. If you're in a must pull down more graphical power case, you're often plugged in and few care about 10s of milliwatts then.

> (As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)

Once again, what is the exemplar of an efficient terminal then. We've already established ghostty doesn't operate the way you think it should so how can it turn out good?

Re: Ghostty 1.0

#692

Any love for Windows. I'm getting restless to ditch putty but unable to find any good emulator that has select and login style of management screen.

I've been happy enough with Microsoft Terminal instead of PuTTY (and I appreciate the open source github repo). If you're comfortable with editing JSON files, you can save the SSH connections as profiles so you can click to open a new tab to whatever SSH session (or WSL setup, or Powershell setup) you want. Example: https://www.howtogeek.com/devops/how-to-set-up-custom-ssh-pr...

Yeah, I've never had a reason to use anything other than Microsoft Terminal on Windows with WSL.

These days, I actually just use the terminal that's built-in to VSCode for everything...

Re: Ghostty 1.0

#693

What am I missing? Can someone please explain what reason there is to switch/build a new terminal when we can use e.g. iTerm ?

Yeah or vscode integrated bash?

This is what I use for everything and it works great. Coworkers look at me crazy when I tell them I never open a dedicated terminal.

Re: Ghostty 1.0

#694

Earlier quoted context omitted.

Search was the first thing I noticed it was lacking. I hope it can be added at some point, sometimes you can't just run a command again to grep it.

The kitty method of piping the scroll back buffer to a pager is more general - it also seems like a quick fix to achieve this desired feature.

I noticed a keybinding for write_scrollback_file (defaults to super+shift+j) which does this. So you can use `grep something ` to search for things. It's a nice workaround until search is implemented.

Re: Ghostty 1.0

#695
post #545

Earlier quoted context omitted.

I'm using Linux with Xfce, but it seems to be locked into a Gnome-like look and feel, with header bars and CSDs that can't be disabled in favor of standard title bars and menus, so it's actually very inconsistent with the rest of my desktop environment.

I was looking into this recently. If you add this to the config, it'll blend in better with XFCE. window-theme = system gtk-titlebar = false gtk-wide-tabs = false gtk-adwaita = false Dunno if anyone will see this comment, but if they do, here is the solution :D

These settings worked, thanks!

After testing Ghostty out for a while, though, I've realized that input lag is higher than xfce4-terminal, font rendering is blurrier with equivalent settings, the UI is still less consistent with my desktop, and it has three to four times the memory footprint on top of all that. Since xfce4-terminal is already using native GTK, so there's nothing gained on that front.

Disabling the UI cruft just turns it into a less performant version of Xterm, so unfortunately, this is going to be an uninstall for me.

Re: Ghostty 1.0

#696
post #267

Earlier quoted context omitted.

>it doesn't support bitmap fonts Very disappointing. Not sure why people are trying to kill off bitmap support in everything these days. Will stick with foot.

IMO the main reason is high DPI screens. On macs it's essentially the default, and it'll probably become the default in the future for everything. Since bitmap fonts make much more sense with low pixel density I think it's not going to be a priority for any newly developed apps.

Bitmap fonts can be scaled by integer factors without losing any crispness, and most high-DPI displays in common use today would look just fine with a 2x or 3x font upscale.

Re: Ghostty 1.0

#697
post #338

Earlier quoted context omitted.

What CLI programs? I have yet to run into any issues after using the built in terminal for its entire lifespan.

As an example, here is the Helix editor (neovim looks just as bad) in Terminal.app vs. ghostty (would look just as good in any other modern terminal). https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C

Off topic but what Helix theme are you using here?

Re: Ghostty 1.0

#698

Many people here seem impressed about speed/performance. I have been using all sorts of terminals / emulators over the past 20 years and it never occurred to me a terminal can be slow. When I type a command, I just get the result instantaneously, for any terminal. What are the use cases that can make a terminal be slow?

> What are the use cases that can make a terminal be slow?

Rendering huge stdout/stderr can be a bottleneck. Try running a program that writes half a million lines of text to stdout without file redirects and a lot of terminal emulators will struggle to keep up.

Re: Ghostty 1.0

#699
post #251

Earlier quoted context omitted.

I’d answer this differently depending on when you ask. 10 years ago (random, but long enough number) I would have said an easy yes. Both GTK and QT would have been acceptable toolkits to use as the cross DE issues weren’t that many and bugs got fixed. Ask me a few years ago and I’d waver. It wasn’t clear how ecosystem friendly GTK4 would be, so I might have optimistically replied the same. But caveat it with a “maybe…

> You’d need to have builds GTK4 & QT Isn’t this just a long about way of saying “no”? Very few frameworks let you flip a switch and build against Qt OR Gtk.

The whole point of marketing an app as being native to an operating system is to appeal to users by saying that you are explicitly not using a framework that lets you flip a switch. That you are going out of your way to make separate builds in the operating system’s native framework so that it looks, feels, and performs as best as possible. That’s very clear in the messaging of how and why the macOS version was built. If you are going to go out of your way to market being native as your differentiating factor, I think that yes, you have to make separate builds of GTK and QT (and in the future, libcosmic if it gets a large percentage of users) in order to be able to genuinely market yourself as Linux native. So it is possible. It’s just not as easy as picking one framework and hand waving away the rest of a substantial portion of the userbase.

I’ll repeat that that is what I find disingenuous with the marketing and about page explanation. I have no problem debating whether or not QT-based desktops are a consequential portion of all Linux users. But if you agree that those users account for a sizable percentage of Linux users, then I think my take is a fair one.

Re: Ghostty 1.0

#700

Earlier quoted context omitted.

well you'll have to get a DD on board to do the work and zig isn't even in debian so that'd have to get there first and the person wanting the terminal probably doesn't want to maintain the programming language as well. So that probably means 2 DDs. Again, there is a non-normal distance here.

That seems like a very Debian problem. Perhaps if one was inclined, Nix can provide immediate resolution, since it can be installed and used on Debian and ghostty project provides convenient flake. Granted I'm on NixOS, but took me grand total of 60 seconds to update config and 8 minutes of actually building on a slow machine.

[dead]
Post reply on HN