• muhyb@programming.dev
      link
      fedilink
      arrow-up
      23
      arrow-down
      2
      ·
      14 days ago

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

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

        • muhyb@programming.dev
          link
          fedilink
          arrow-up
          22
          ·
          13 days ago

          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.
          • Sturgist@lemmy.ca
            link
            fedilink
            arrow-up
            9
            ·
            13 days ago

            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.

            • muhyb@programming.dev
              link
              fedilink
              arrow-up
              2
              ·
              13 days ago

              Yeah, it’s one of the greatest characteristics of FOSS. We have many options and endless posibilities.

              Glad to help.

  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    6
    ·
    13 days ago

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

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

    • geneva_convenience@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      13 days 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.

    • PetteriPano@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      13 days 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… 👌

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      13 days ago

      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.

    • MonkderVierte@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      13 days ago

      The “Abandon all hope, ye who enter here” terminal?

      Edit: that was once a comment in the sourcecode.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        13 days ago

        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. :-)

  • MonkderVierte@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    13 days ago

    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?

  • trevor@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    9
    ·
    edit-2
    12 days ago

    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.

    • asdfasdfasdf@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      12 days ago

      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.

      • trevor@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        12 days 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.

    • Classy@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      arrow-down
      8
      ·
      14 days ago

      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

      • Nibodhika@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        13 days ago

        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.

      • cybersandwich@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        13 days ago

        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.

  • Euro@lemmy.ml
    link
    fedilink
    Norsk bokmål
    arrow-up
    2
    ·
    11 days ago

    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/random for whatever reason

    For 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 rustc to test yourself.

    running the binary with hyperfine, i get ~35ms on my current terminal (foot), and ~40ms on ghostty.

    The terminal window sizes about the same size, in fact, there were 3 extra lines in foot so 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.

  • w3dd1e@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    13 days ago

    But does it roll down like Yakuake did before I updated Fedora and broke it? :( That’s all I want.

    • Crestwave@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      13 days ago

      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?

      • brie@programming.dev
        link
        fedilink
        English
        arrow-up
        16
        arrow-down
        5
        ·
        13 days ago

        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.

        • Crestwave@lemmy.world
          link
          fedilink
          arrow-up
          17
          ·
          edit-2
          13 days ago

          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. :-)

          • brie@programming.dev
            link
            fedilink
            English
            arrow-up
            4
            ·
            13 days ago

            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.

              • brie@programming.dev
                link
                fedilink
                English
                arrow-up
                1
                ·
                13 days ago

                Fair. I hate kube though. Most companies run just 10 pods because they cargo cult google. The complexity of it is completely unjustified

                • FrederikNJS@lemm.ee
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  12 days ago

                  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.