6 ms·
A lot of places still have pretty slow/unreliable internet. Developing countries often end up being basically mobile-only because it requires less infrastructur
by enkiv2 7y ago
A lot of places still have pretty slow/unreliable internet. Developing countries often end up being basically mobile-only because it requires less infrastructure, but mobile-only doesn't mean 4G in such places. Other times, relatively rich countries will have spotty internet access because of geography: New Zealand famously had very poor internet service for a while because of the complexity around getting cables there, and Australia has such a big difference in population density between urban and rural areas that wiring infrastructure in the sticks is tough. Even in the united states, a surprising number of people are still using dial-up internet because broadband is not available.
Another concern is embedded platforms. If rust can't produce meaningful code that's under a megabyte, then it can't be used to write elevator controllers or microwave oven displays or to program pacemakers -- and as regular computers get more RAM to try to make up for the end of Moore's law, a larger and larger percentage of cases where it makes sense to use a compiled systems language over a JITed scripting language will be embedded ones. To some people, if a compiler can't produce 1k binaries, it's worthless because it forces you to substitute in a beefier machine.
There's also general performance and security concerns: any unnecessary code adds to both vulnerability surface & footprint. If you work your system really hard & you're always a meg or two short of running out of RAM, then saving a meg or two of code size matters a whole lot. (This applies less to desktops & more to applications where you might process lots of data on off-the-shelf hardware: if you're clever & take advantage of parallelism, you can process many TB of data on a machine with less than a gig of ram in a relatively short time, and you can cut it down further if you can run more copies of your application, which you can do better if your memory footprint is smaller.)
Finally, I don't think it's safe to overestimate what percentage of machines are less than eleven years old. Ever since Moore's Law ended, the case for upgrading hardware has been a lot weaker, and even when it was running strong folks often went a decade without doing so.
Bloat doesn't necessarily translate into usability, and usability doesn't necessarily transfer between users. There are a lot of folks for whom a 5mb app is, necessarily, unusable.
- nikisweeting 7y ago> "unnecessary code adds to both vulnerability surface & footprint" I wholeheartedly agree with this. If there is unnecessary code, there's no reason to keep it. I'm more directing my gripes towards packages that have highly desirable, well-audited add-ons / modules that package maintainers choose not to include in the default distributions (under the reasoning that "users want small binaries"). Take for example nginx, caddy, certbot, or postfix (there are many others too). All of these require recompiling from source with build flags to enable the inclusion of even their most common add-on modules, e.g. nginx_http_lua_module, nginx_http_perl_module, caddy:http.cache, cerbot dns plugins, etc. Recompiling from source breaks the ability to use a package manager for install and automated updates, which drastically reduces usability for the majority of users. There are ways around this of course, but for the average user, having to compile a package from source is a major hurdle. Instead, why not distribute the binary with no add-ons as "apt install packagename-minimal" for the users with bad internet / low-resource requirements, and make the default "apt install packagename" distribution the "batteries included" version? (If you're interested, here's an old blog post of mine that goes into detail on why I think package manager distributions are worth the effort to maintain in general, even for static binaries or packages with dylibs: https://docs.sweeting.me/s/against-curl-sh https://docs.sweeting.me/s/against-curl-sh)
- human20190310 7y agoChoosing to include nothing by default is easier than having the argument about which modules meet the "highly desirable" standard.
- coryrc 7y agoInstall nginx-extra then?
- deleted 7y ago[deleted]
- nikisweeting 7y agoBut why not have that default and the non-extras version 'apt install nginx-minimal'? What about caddy which doesn't offer module support at all in the package manager verserion? Certbot and postfix also don't include their most commonly used modules out of the box.
- mholt 7y agoIf apt and others could simply allow us (package authors) to construct a URL from which the binary can be downloaded, and then plop it into the user's PATH for them, this would not be a problem. (What I'm getting at is that all it takes to install a custom build of Caddy -- with any number of plugins you want -- is a GET request.)
- _bxg1 7y agoYour whole first paragraph is about the web, which the OP specifically said they weren't talking about.
- saagarjha 7y agoMany people download binaries from the internet.
- _bxg1 7y agoSure, but when it's a binary you only do it once, at which point seconds (or even a couple minutes) become mostly a non-issue.
- forgotmypw 7y agoSpoken like someone who doesn't know/remember using a slow connection...
- andoriyu 7y agoIt doesn't matter what you or I remember. When we talking about optimizing _binaries_ for size, we're talking about saving kilobytes maybe a megabyte or two. That has no effect on how long it takes to download it, but help with: - Less dependencies to follow - Maybe even benefit from instruction cache - Shorter compile times - People don't laugh at you when you have half gigabyte of binaries to start an rds instance and create a user in it. (wtf hashicorp?) - Smaller attack surface - Som now started to target WASM as secondary target and then suddenly it's not web, but also web
- nikisweeting 7y agoI grew up on <1mbps internet and still managed to download 8k+ mp3s and hundreds of movies. It was slow going, but my expectations were low given that's all the bandwidth I'd ever had, so I wasn't frustrated by it until I tried 20mbps one day.