this post was submitted on 26 Dec 2024
175 points (95.8% liked)

Linux

48740 readers
1180 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 8 points 12 hours ago* (last edited 12 hours ago) (1 children)

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 with time ./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 find on 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.

[–] [email protected] 4 points 11 hours ago (1 children)

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.

[–] [email protected] 1 points 11 hours ago* (last edited 10 hours ago)

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, find has many uses, many of which will print data to the screen, and find is 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.

[–] [email protected] 10 points 1 day ago (2 children)

Thought out choice but disappointing nevertheless:

My stance for now is that Ghostty will not support sixels.

[–] [email protected] 1 points 6 hours ago

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?

[–] [email protected] 3 points 16 hours ago

What do you think about the Kitty Graphics Protocol?

[–] [email protected] 90 points 2 days ago (2 children)

Cool project and... no screenshots? 😭
Every. Damn. Time.

[–] [email protected] 4 points 1 day ago
[–] [email protected] 2 points 1 day ago* (last edited 1 day ago) (1 children)

I mean, it's a terminal emulator; what's it supposed to show, a bunch of white text on black background?

[–] [email protected] 6 points 1 day ago (1 children)

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

[–] [email protected] 3 points 15 hours ago (1 children)

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.

[–] [email protected] 1 points 14 hours ago* (last edited 14 hours ago) (1 children)

By "can only be felt" do you mean in the way it affects the performance of your system?

[–] [email protected] 1 points 11 hours ago* (last edited 11 hours ago) (1 children)

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.

[–] [email protected] 1 points 5 hours ago

Sorry, what does w.r.t. stand for?

No terminal emulator ever should affect the performance of the rest of your system.

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

[–] [email protected] 13 points 1 day ago* (last edited 1 day ago)

Looked at it, interesting, no package, installed cosmic-term instead

Uses alacritty under the hood, with tabs and tiles!

[–] [email protected] 26 points 2 days ago (6 children)

It's ridiculous how much time people are spending performance optimizing terminals.

xterm on a 120MHz Pentium on X11 in the 90s performed "fine".

[–] [email protected] 42 points 1 day ago (1 children)

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.

[–] [email protected] 7 points 1 day ago

"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...

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.

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.

[–] [email protected] 3 points 1 day ago

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.. 👌

[–] [email protected] 4 points 1 day ago

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.

load more comments (3 replies)
[–] [email protected] 12 points 1 day ago (1 children)

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?

[–] [email protected] 6 points 1 day ago* (last edited 1 day ago) (4 children)

Checked the build.zig file for ghostty, seems to be for manpage generation. Zig itself doesn't use Haskell though

load more comments (4 replies)
[–] [email protected] 35 points 2 days ago (2 children)

What are the differences between all of these terminals?

[–] [email protected] 36 points 2 days ago (1 children)

If you're occasionally using them, there aren't any.

If you're excessively using them, there are many.

[–] [email protected] 11 points 1 day ago (1 children)

Could you highlight a couple, I'm kinda in between with my terminal usage....

[–] [email protected] 29 points 1 day ago (1 children)

Sure, I can do that.

  • If you're looking for something lightweight, go for st or urxvt. These are Xorg-only.
  • If you want to configure it via GUI, xfce4-terminal is the middle ground for lightweight and feature-rich. If you are on KDE, konsole would suffice. You can use these on Xorg and Wayland.
  • If you want to work with multiple panes in a single window, terminator is your friend. Used this on Xorg but not sure about its Wayland compatibility.
  • If you want GPU acceleration and more features, kitty and alacritty is out there. Both should work on Xorg and Wayland.
  • If you want something like st but pure Wayland, foot is the best lightweight terminal emulator. My current personal favourite.
[–] [email protected] 9 points 1 day ago (1 children)

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.

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 8 points 1 day ago (2 children)

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?

[–] [email protected] 9 points 1 day ago (1 children)

It works natively on Wayland. The UI uses gtk4.

[–] [email protected] 1 points 11 hours ago* (last edited 7 hours ago)

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.

load more comments (1 replies)
load more comments
view more: next ›