The gzipped tar for this is 90MB. It's 265MB unzipped.
That's bigger than my kernel, my initramfs, all my terminal emulators, my media player, glibc and the gnu coreutils together, and I'd still have room to spare for some mp3s.
No.
That's bigger than my kernel, my initramfs, all my terminal emulators, my media player, glibc and the gnu coreutils together, and I'd still have room to spare for some mp3s.
No.
Given it won't run on my Raspi. But there can still be value in things that don't run on micro computers.
And neither is battery power. A terminal application is supposed to be small, and next to invisible in terms of resources required. If it isn't, it will be uninstalled.
According to whom? The terminal gods?
According to wikipedia:
"A terminal emulator, terminal application, or term, is a computer program that emulates a video terminal within some other display architecture. Though typically synonymous with a shell or text terminal, the term terminal covers all remote terminals, including graphical interfaces."
I don't see anything in there about "invisible in terms of resources required"
In that strictest sense of the word, even an RDP client onto a windows desktop is a "terminal".
As the article points out itself however: The colloquial semantic meaning of the word, aka. what is usually meant by it, is TEXT TERMINAL.
And btw.: Even for a fully featured RDP client, I wouldn't accept a size of 200+MB. The one I use at work is barely 4MB.
Your parent isn't forcing anyone to choose the same way as them. They're just advertising facts that inform a buyer when choosing. Your aggression, on the other hand ...
> ... pooh poohing something just because it doesn't fit your idea of productivity apps isn't very helpful.
The way you're pooh poohing your parent's criticism because it doesn't fit your idea of what matters and what not, isn't very helpful.
And even if it were, the size of an application in relation to its purpose is a relevant metric.
Our ancestors would argue that a 1MB application was bloated. Our children will complain about 1000GB bundles.
The programs, of course, do vastly different things as the realm of what is possible with technology inexorably advances.
Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges, and the curmudgeons who are shaking their collective canes at the kids on their lawn are actually technically competent and can recognize this if they choose.
There are legitimate technical criticisms to doing things with JS and Electron and whatnot; but "the bundle is hundreds of megabytes" isn't that.
No, we really don't, because these libraries are available to other programs as well, whereas a huge packaged application is availabe to nothing than itself.
> To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly.
That's like saying, to compare Usain Bolt and myself in terms of sprinting performance, you should consider the fact that I'm chubby for a fair comparison.
(I know of the suckless community and of st in particular (I've never tried it)).
"It is 250MB" alone isn't.
This slowness costs users so many hairs pulled out. Programmers who think that "this is acceptable" lack the awareness that they haven't even tested the software under only slightly unusual conditions which is when everything is already crawling to a halt.
When that "bundle" is 1000MB while technically there is no reason it should be more than ~1MB, many operations that you might want to do as a developer / trying-outer of the bundle take 1000x longer (no shit). Not unlikely, in some cases that even applies to runtime performance.
Why in the world would you accept that when it takes only a little discipline to get it down to a "reasonable" overhead of say, 10x???
Not all software is getting slower faster than hardware is getting faster.
It has always been possible to write slow software.
But to your actual point, of course you can write software that runs not slower, or even runs much faster, than the software of 30 years ago that ran on machines of the time. The exception proves the rule (while I feel it's always been so obvious that there was never a proof needed).
And the important point is: it _is_ annoying, an actual bootup in 5 seconds is easily possible from a technical perspective, and would much improve the user experience.
Take systemd, I remember it brought a lot of startup time improvements for a while, or at least promised them. I don't follow Linux very much these days, but when I do a standard installation of a popular distro - sloooow startup. Last I looked I had an issue with tons of virtual serial devices created serially, took probably 10 seconds alone.
Parkinson's law at work.
And no one listened, so now -- despite our computers being thousands of times faster -- basic applications are hundreds of times slower to open. And we're junking a bunch of "old" machines that are considered too slow even though they're technically capable of performing rapid operations at levels our brains can barely comprehend.
They still do, thank you very much.
Our children will still complain about a 10MB application, if it does something that could be done by a 500KB solution.
>Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges,
And what do I need a "advanced graphical application framework" for if the intended use case is displaying text in a grid?
Good for you, I guess. I, myself, have 120GB.