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

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

The easiest way to tell if you have a vitamin deficiency is to ask your doctor. Random websites are not medical advice.

Bash and zsh aren’t terminals. They’re shells.

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

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

Whichever one doesn’t crash while I’m trying to do something.

So usually neither…

Are they free range and GMO free? 🙄

I don’t look for apps based on what language they’re written in.

And I sure as hell don’t install apps that use “curl” to fetch an install script and pipe it to a shell. This practice needs to die in a fire.

Linux has been very successful without catering to those who don’t want to learn new things.

Why would I want gui for those things? CLI is often a better interface. Being able to grep lsusb rather than scanning a gui for an entry is much better. It’s easier to pipe to an email as well. Screenshots don’t allow copy/paste…

Better? This is absolutely awful if you have more than a handful of directories and files. It just shows the top directories and excludes everything that doesn’t fit. Directory names are truncated if they don’t fit so it’s difficult to know what “ti[…]e/” is… And you get this weird XXXXX lump for small files.

gdu is a slightly “nicer” looking ncdu and much faster than this.

I’m also curious experimenting with a no-GPU setup.

In my limited experimentation on a 12th Gen Intel® Core™ i7-12700H with 64GB of RAM this is probably not worth it for anything beyond simple usage. You can do it but I get something like 4-5 toks/sec with LLama 3B Instruct and that’s one of the faster models.

That’s crazy - does it not have any thermal protection? I’ve had CPUs overheat and they tend to throttle/shutdown before I’ve had anything damaged.

That’s what libraries do. glibc converts application calls to Linux syscalls. libgl converts application calls to driver calls.

It depends on where you draw the line at “native”. Unless you’re writing assembly you’re using some sort of ‘compatibility layer’.

It runs natively. Compatibility layer or not.

You know what WINE stands for?

What’s the point to reactos? I don’t want to just run windows applications, I want to run Linux. WINE is the better approach. I can run windows applications and still run Linux.

WINE does run wiindows apps natively on linux.

If by “toys” you mean like “linux” and “git” then no.

Edit to expand: They aren’t really his. They’re GPL’d so anyone can do anything* with them

• within the provisions of the GPL

That was goddamn amazing.