Looks like the macOS binary size is a combination of shipping 3 binaries, each with most of the application compiled in (and statically linked), and containing builds for both Apple Silicon and x86 in each.
Keep in mind, wezterm is a statically linked binary, while builtin and distro-provided packages will use dynamic linking. Depending on how it's built, it may also have embedded debuginfo and lack LTO.
Rust has the NodeJS/Python dependency tree bloat problem.
Unlike other terminal emulators, this project is entirely statically compiled, so the code for the built-in SSH client, serial port support, muxing server/client protocol, shader compilation engines, image decoding libraries, D-BUS clients, threading libraries, HTTP(S) (1.1/2/3) with several types of compression, and of course the GPU shader compilers and APIs.
I built Wezterm on my machine and the binary is about 21MiB in size. About 12MB of that is code, the rest is debug symbols. 2MB of that is the Rust standard library and another 1MB is a LUA runtime. Then there are several image libraries that take about half a megabyte.
The compiled source code itself is only 893KiB in my file. The rest is just dependencies and random ELF segments.
So yes, the terminal emulator is about one Windows 95 installation in size, but that's all quite explainable if you care about the features.
For comparison, I've run `debtree` on gnome-terminal (3.4KiB on disk) and the dependency tree is reported to be 691MiB. Microsoft's Windows Terminal is distributed in 18.6MiB - 66.4MiB (I don't know the compression msixbundles use if any) which is comparable. iTerm2 seems to be about 74MiB decompressed. Even `xterm` (the most barebones terminal emulator I can find) relies on 20MiB of dependencies.
If xterm is all you need, then there's no need to download anything else. If you want more features in a terminal emulator, you're going to have to deal with larger binaries.
This is the size of the binary or RAM usage? If the size the binary, does it matter in most cases? If the size of RAM, yeah, I can see how that seems a lot for a terminal.
The binary is statically linked and embeds several fonts for a consistent, cross-platform, out of the box experience.
The on-disk size != RAM usage, and on-disk size really doesn't matter on modern systems, unless you're on a very resource constrained system, in which case, you probably don't want a feature-heavy GUI anyway.
If I compare this feature list to e.g. features of xterm (VT52/VT100/VT220/VT320/VT420/partial VT520 support, graphics via Sixel/ReGIS/Tek4014, …), I don't see a single reason why wezterm should be roughly 100MB large (according to pacman on Archlinux) vs roughly 1MB for xterm.
If you think "but terminal multiplexing and SSH!", then feel free to add 0.9MB for screen (or 1MB for tmux) and 4.8MB for openssh, and you're still way below the size of wezterm.
idk, I am with you and I don't typically care about sizes like this, but this does feel like quite a lot, although not as much as reported above. The split between the two rust programs here is pretty interesting.
[nix-shell:~]$ du -hs $(nix-build '<nixpkgs>' -A wezterm)
Alacritty is basically as minimal a terminal emulator as you're going to get, wezterm is the polar opposite end of the spectrum. Kitty is in the middle, the main thing that wezterm has that kitty doesn't that I'm aware of is the daemon process that allows you to disconnect/reconnect to sessions which is what allows wezterm to function as a tmux replacement (vs kitty can't replace that aspect of tmux). Compared to alacritty, it has multiplexing, ssh sessions (new tabs/panes opened in that session are opened in the context of the remote host without requiring additional authentication), incredibly flexible configuration via lua, etc. And as far as size goes, kitty and wezterm are written in different languages so comparing them directly is not so simple.
This does seem crazy. I have a hobby project that's a statically linked animation editor (so it does a lot of stuff including exporting/encoding GPU streams into a video). It has AV1, Freetype, and a few other large deps included and it only clocks in at 16.7mb
People hated on Apple for the touch bar, but this is the natural evolution of the keyboard, why stick to fixed physical keys when you can have them digitalized to be context aware
The problem will be the price
Mechanical keyboard market already is a scam where 90% of products are greatly overpriced, that will not encourage them to offer a reasonable price unfortunately
EDIT:
The keyboard will cost between US$299 - $350 after discounts for pre-orders with a retail price of US$450.
Yeah, the price of a console-tier GPU, way too overpriced to be a successful product
Are you kidding, I saw a mouse the other day selling for two hundred bucks. Provided that by some miracle this has a good keyboard feel, I can imagine entire shops switching over to this in specialized industries, plus loads of gamers, translators, people wanting it as a status symbol. It could even be something of a security measure by obfuscating the keys during login. Even perhaps a laptop manufacturer can license their tech for dual screen laptops like the Lenovo Yoga Book 9i. It wouldn't even be a $400
> 8. Civil war will break out in the US, California. and Texas becoming independent states as a result. Texas and Mexico will form an allied state. Elon Musk’ll win the presidential election in a number of states which, after the new Civil War’s end, will have been given to the GOP
About Mexico, the president rejected Tesla's plan to build in his country but few days later gave his approval
It not people who want to cash out. Actually it’s people who can’t cash out otherwise, but will still have a huge tax bill if they exercise before the options expire. The only other choice for these employees would be to simply allow millions of Dollars (each) of options to expire.
that's worse than an electron terminal
something is wrong