[HN Gopher] How fat does a fat binary need to be? (2021)
___________________________________________________________________
How fat does a fat binary need to be? (2021)
Author : draugadrotten
Score : 238 points
Date : 2022-08-30 09:31 UTC (13 hours ago)
(HTM) web link (justine.lol)
(TXT) w3m dump (justine.lol)
| yakubin wrote:
| That's a quasi-dupe of
| <https://news.ycombinator.com/item?id=32642874>.
| capableweb wrote:
| Don't think so, although they are complementary. Submission you
| link is more like a reference/article while the submission
| we're commenting on, is more like an application/demonstration
| of said technique.
| gwbas1c wrote:
| It says Windows, but is it x86 or x64?
|
| Can it make a binary that's both x86 and x64 for Windows? Is that
| even possible?
| poizan42 wrote:
| > It says Windows, but is it x86 or x64?
|
| x64
|
| > Can it make a binary that's both x86 and x64 for Windows?
|
| Seems to be a PE32+, so it won't run on 32-bit Windows.
|
| > Is that even possible?
|
| Yes, it should be. A 32-bit process on 64-bit Windows can run
| 64-bit code by changing the segment selector - make a far call
| or jump to 0x33:<address>. See [0] for more details.
|
| There are some caveats though. kernel32.dll refuses to be
| loaded as both the 32-bit and 64-bit versions in the same
| executable. So the executable can probably only import ntdll.
| One thing one might do is just compile both a 32-bit and 64-bit
| version of the actual program as dll's and embed them inside
| the launcher and then extract and load them using only api's in
| ntdll. In the case of APE it would probably just embed an
| x64-on-x86 emulator and run the executable in that in case it's
| being run on x86.
|
| Another solution might be to create a .NET AnyCPU executable
| which will run as 64-bit on 64-bit versions of Windows.
|
| [0]: https://www.malwaretech.com/2014/02/the-0x33-segment-
| selecto...
| TillE wrote:
| I don't think so, the PE headers are different.
|
| If you really wanted to, you could hack your own "fat binary"
| format by packing the 64-bit EXE as a resource within an x86
| binary that detects the current architecture, but that's not
| very exciting.
| Comevius wrote:
| The PE format is used, and the cosmopolitan libc example was
| compiled for x64.
|
| PE requires a single machine type to be specified, but these
| days there are support for hybrid binaries with the ARM64EC ABI
| (which follows x64 conventions and can include both x64 and
| ARM64 code) and fat binaries with the ARM64X ABI (can include
| both ARM64EC and ARM64 code).
| TruthWillHurt wrote:
| Mate, you gotta relax a bit. You're making the rest of us look
| bad.
| cauefcr wrote:
| Just don't compare against tour-de-forces from these geniuses,
| much easier (and what I do).
| civilized wrote:
| Was the 12 removed by that horrible bookmarklet that
| automatically removes words it doesn't like?
| kubb wrote:
| This is really cool! I have a question for people who know this
| stuff: what's the "f.Va" pattern that appears at the end of these
| binaries? It looks intriguing...
| jart wrote:
| That's a fat nop, or cs nopw 0x0(%rax,%rax,1) to be precise.
| .byte 0x66,0x2e,0x0f,0x1f,0x84,0x00,0x00,0x00 # f.Va
| .byte 0x00,0x00
|
| ld.bfd uses them to fill empty spaces. See also
| `o//tool/decode/x86opinfo.com 66 2e 0f 1f 84 00 00 00 00 00`
| and https://justine.lol/dox/modrm.txt and
| https://justine.lol/dox/geek.txt
| stiray wrote:
| If I remember correctly from the DOS times, the limit for com
| files was 64KB. I haven't tried to compile one for ages, is this
| any different on Windows NT+ (I would try but I dont have a
| single windows machine at home)?
| jhoechtl wrote:
| I think you are right.
|
| Totally cheating would be to integrate the DOS application
| functionally into the Windows DOS stub. Instead of printing
| "This application requires Microsoft Windows" it could even use
| overlays to circumvent the 64kB com restriction.
| tripa wrote:
| The limit for a .COM's useful payload is 64KiB, but that
| wouldn't necessarily prevent the actual file from being bigger,
| with either truncate or wrapover semantics.
| petercooper wrote:
| Ready to be corrected, as I haven't worked with DOS or Windows
| for decades, but I seem to recall ".com" is merely used for
| familiarity/compatibility and hasn't meant anything about the
| underlying format for a very long time now.
|
| The Wikipedia page for .com suggests that 64 bit Windows NT+
| systems can't run the original style .com files anymore due to
| lacking the MS-DOS emulation subsystem, so the point may be
| moot.
| TazeTSchnitzel wrote:
| Already thirty years ago there were DOS executables with a
| .COM extension that weren't actually in the COM format.
| COMMAND.COM in later versions of DOS is an example.
| swills wrote:
| Go has it's own run time, right? Why doesn't it do this?
| georgia_peach wrote:
| https://github.com/jart/cosmopolitan/issues/140
|
| https://github.com/golang/go/issues/51900
|
| & from what I gather, APE is tightly-bound to x86_64, & depends
| on an embedded emulator for other architectures:
|
| > _All we have to do embed an ARM build of the emulator above
| within our x86 executables, and have them morph and re-exec
| appropriately, similar to how Cosmopolitan is already doing
| doing with qemu-x86_64, except that this wouldn 't need to be
| installed beforehand. The tradeoff is that, if we do this,
| binaries will only be 10x smaller than Go's Hello World,
| instead of 100x smaller._
|
| could still be useful as an optional build target though...
| (i.e. GOOS=cosmopolitan)
| jart wrote:
| Please support our runtime proposal
| https://github.com/golang/go/issues/51900 We're trying to add
| Cosmopolitan to Go's list of supported runtimes!
| georgia_peach wrote:
| This thing of yours is quite an accomplishment. Even so, I
| hope it goes no further. If it does (& it probably will,
| because it is _convenient_ ), most of the computing world
| will have stacked yet another sub-optimal low-level mono-
| culture on top of the one that was already there.
|
| From the robustness/survivability perspective, the mono-
| cultures we have are bad enough.
| jart wrote:
| Yes we're already stuck with all these mono-cultures, so
| why not just define the union of all these mono-cultures
| into a single build target?
| georgia_peach wrote:
| In the world where a windows binary is not expected to
| run on a mac, and vice versa, they still have the option
| to change things on an as-needed basis (like the golang
| breakage on osx). In a world filled with APEs, you will
| have canonized all of the present OS idiosyncrasies that
| made APE possible in the first place, & we will be stuck
| with them forever.
| jart wrote:
| Nah eventually every operating system is just going to
| support x86_64-linux-gnu and there won't be a need for
| APE in our glorious future. In that case, Cosmopolitan
| will just be a non-GPL libc that goes as fast as Glibc.
| But until all operating systems become fully developed,
| we have an outstanding hack to hold us over.
| georgia_peach wrote:
| > eventually every operating system is just going to
| support x86_64-linux-gnu
|
| Whether it's batteries included, or batteries sold
| separately, we'll still be stuck with batteries. If I
| want to run Linux on my Mac, that's what UTM is for.
|
| Despite my reservations, nothing but respect, & enjoyed
| your Feross presentation.
| justinmchase wrote:
| Essentially it comes with a garbage collector which gets
| embedded into your binary as well as any other standard library
| calls you may need for fundamental features.
| rcgorton wrote:
| encryptluks2 wrote:
| I don't understand what the issue is with cross-compiling
| software, especially for different architectures. This seems more
| geared for running a binary on the same architecture across
| multiple different operating systems. This is great and all until
| you use some API that isn't the same on those operating systems.
| I imagine once you see something like this attempting to use
| comparable features and APIs as Go or something else, that you'll
| see the bloat increase to be equal in size if not more.
| diffxx wrote:
| > I don't understand what the issue is with cross-compiling
| software, especially for different architectures.
|
| Agreed. The cosmopolitan project is incredible hacking and I
| appreciate the author's ingenuity, but this has always felt a
| little bit to me like a solution in search of a problem. How is
| cosmopolitan software intended to be distributed? If the answer
| is on the internet, I don't see how a single fat binary helps
| the end user dramatically more than separate download links.
| For the developer, cross compilation can be automated as part
| of deployment. The platform specific binaries should both be
| smaller than the universal ape binaries and won't resort to
| hackery to work properly.
| jart wrote:
| Because end users use multiple operating systems these days.
|
| Also, no. The operating system integration code is tiny in
| the grand scheme of things. Consider Fabrice Bellard's
| JavaScript interpreter. If I build it for six operating
| systems, then it's 782kB: master
| jart@nightmare:~/cosmo2$ ls -hal
| o/tiny/third_party/quickjs/qjs.com -rwxr-xr-x 1 jart
| jart 782K Aug 30 10:53 o/tiny/third_party/quickjs/qjs.com
|
| If I build it for just Linux, then it's 710kB:
| master jart@nightmare:~/cosmo2$ ls -hal
| o/tinylinux/third_party/quickjs/qjs.com -rwxr-xr-x 1
| jart jart 710K Aug 30 10:52
| o/tinylinux/third_party/quickjs/qjs.com
|
| That's a 72kB difference, which includes all those Windows NT
| hacks and bare metal support. Why not just stuff it in there
| and be done with it? That way you only have to list one file
| on your download site.
| ghoward wrote:
| This is still a solution in search of a problem. Hosting
| artifacts is not that expensive. Disk space is cheap.
| kelnos wrote:
| > _Because end users use multiple operating systems these
| days._
|
| Do end users commonly want to copy programs between OSes,
| or will they usually just revisit the project's website and
| download it again? My feeling is it would be the latter.
|
| And if we're talking about running multiple OSes on the
| same computer, is it common to share filesystems between
| those OSes? It's been a while since I ran more than one OS,
| but trying to do that wasn't remotely pleasant.
|
| I think this is a huge technical achievement, and I do
| think there are some use cases for it here and there, but I
| personally don't see a big benefit over just using a CI
| system to automatically create a build for each OS/arch
| combination at release time.
|
| I also wonder about the trade offs involved in using a
| different libc. As an example, when I was looking into
| musl, I realized that it didn't use NSS (unsurprising,
| since that would defeat the whole zero-dependency static
| linking thing), and therefore had no support for multicast
| DNS (well, not that NSS is required, but they also didn't,
| and had no plans to, integrate mDNS support of their own).
| I've pretty much abandoned using musl (and Alpine for
| containers) due to random quirks and gotchas like this that
| end up biting me somewhere down the line.
| jart wrote:
| Are you telling me that you don't see the benefit to
| clicking a build button on Linux, scp'ing to your
| website, and saying done -- versus -- setting up Jenkins,
| buying a Windows license, buying an Apple license,
| setting up six VMs, and then once your devops industry is
| in place, waiting fifteen minutes for the thing to build
| across all N platforms, and assuming there's no error
| with all your #ifdef soup needed to support building on
| six different operating systems with six different sets
| of tools, then extracting your binaries from all the
| Jenkins instances, scp'ing them to your website and
| setting up a download link for each one, and finally
| hoping that the end user clicks the correct one -- I mean
| are you being serious? Why use APE when you can just hire
| a devops team to do your releases.
| encryptluks2 wrote:
| Tools like go-releaser does everything you said already
| automatically and doesn't need 6 different operating
| systems and can be ran on GitHub. Also, why would you not
| just use the built-in package manager to install an app?
| I don't think anyone is denying that it is an achievement
| and has limited purpose but in my opinion you're overly
| enthusiastic about it and in the real world it isn't that
| practical. I hate to say it but fanatics sometimes ruin
| cool stuff because they want everyone to be as fanatic as
| them.
| jessermeyer wrote:
| We are slaves to the current system.
| NateEag wrote:
| I think the main appeal is the simplicity.
|
| There's one deliverable.
|
| One.
|
| Users _cannot_ download the wrong build, because the wrong
| build doesn 't exist.
| [deleted]
| nudpiedo wrote:
| I actually like a lot the idea, and it's impressive, however
| nowadays there is also the challenge of many consumer
| architectures on the commodity desktops, not just x86 like it
| used to be.
|
| I guess that, and shared libraries ABI, is the biggest challenge
| now.
| jeroenhd wrote:
| Technically the executable only runs on 6 operating systems as
| the 7th option basically turns the application into an operating
| system running on bare metal.
|
| Justine's impressive work on this subject makes me wonder if it's
| possible to build truly native applications using more complete
| toolsets and more modern languages. Multiplatform toy programs
| have existed for ages, but this SDK of sorts makes it possible to
| write executables that don't require manually tricking the
| compiler or adjusting your code for portability with inline
| assembly. As long as the program is statically compiled and
| contains the necessary drivers for things like syscalls, this
| should be perfectly possible, though the current implementation
| isn't exactly user friendly, relying on giant headers like
| https://justine.lol/cosmopolitan/cosmopolitan.h, statically
| linked components like https://justine.lol/cosmopolitan/crt.o and
| https://justine.lol/cosmopolitan/ape.o, and other such tweaks.
|
| I'd love a Go/Rust compile target that just works regardless of
| operating system. As an added bonus, the bare metal nature would
| be excellent for platforms like Firecracker to run services
| without even needing to boot a kernel!
| behnamoh wrote:
| I would even argue that it runs on 3 (or 4 if I'm generous).
| From the website:
|
| > Linux, Mac, Windows, FreeBSD, OpenBSD, NetBSD, and BIOS
|
| 1. Windows
|
| 2. Linux
|
| 3. Mac (which is a descendent of BSD, though with different
| kernel.)
|
| 4. BSD (including FreeBSD, OpenBSD, NetBSD)
|
| The "OS" in BIOS doesn't stand for Operating System! It's Basic
| Input/Output System.
| noselasd wrote:
| Hmm, linux also use ELF, as does the BSDs - but an normal
| executable is still not compatible across any of the 4 OSs.
| There isn't any good reason to lump them together.
| kelnos wrote:
| Can you build a binary on NetBSD with gcc or whatever, linked
| to the system libc (or whatever usually happens by default),
| such that you can copy it over to a FreeBSD or OpenBSD system
| and it'll just run, without having to install any kind of
| special compat or emulation layer?
|
| If so, ok, sure, then you have a point. Otherwise, no, those
| are three distinct OSes, and it's entirely correct to list
| them as such.
|
| I _know_ you can 't mix macOS into that, so the "or 4 if I'm
| generous" is pretty unfair.
|
| > _The "OS" in BIOS doesn't stand for Operating System! It's
| Basic Input/Output System._
|
| I don't think the author is claiming it means "Operating
| System", just that "BIOS" is a simple shorthand for "bare
| metal". Which no, isn't an "operating system" in the
| classical sense, but it is a standardized set of very low-
| level system services that sorta vaguely kinda acts like one.
| And if we consider UEFI rather than old-school PC-BIOS, it's
| even more like an OS.
|
| Your comment just feels like pedantry for pedantry's sake
| (and not particularly correct pedantry, at that). Not sure
| what you're trying to accomplish here by minimizing the
| achievement.
| yjftsjthsd-h wrote:
| > BSD (including FreeBSD, OpenBSD, NetBSD)
|
| I'm going to strongly disagree; BSD hasn't been a single
| operating system since 1995 (4.4BSD-Lite Release 2, the last
| BSD version from Berkeley). The extant BSDs are closely
| related, derive from a common original source, and semi-
| frequently share code back and forth, but they're separate
| systems with different code and different ABIs.
| smm11 wrote:
| I read 7 and just knew it would list every BSD instance
| possible except OS X, then GNU would just HAVE to be there.
| laumars wrote:
| macOS (it's not called OS X any more) is listed as XNU.
|
| And of course it would list every BSD instance. Supporting
| them isn't automatic when you're taking about pre-compiles
| binaries because they can have subtly different ABIs. POSIX
| helps here but mostly at the source level, an ELF compiled
| for FreeBSD wouldn't automatically run on OpenBSD nor
| NetBSD. The fact this does is unusual and deserves calling
| out.
| gwbas1c wrote:
| Keep in mind that, although this is a cool concept; in practice
| everything needs an installer. (IE, a .msi file or a Setup.exe
| for Windows, a .dmg or a .pkg for Mac, and whatever Linux
| requires.)
|
| And, if you're shipping into an app store, there's really no
| point in using something like this.
| mattl wrote:
| A disk image isn't an installer though and it could just be
| an app bundle in a ZIP file or similar.
| yjftsjthsd-h wrote:
| Er. Windows has Portable Apps (especially of
| https://portableapps.com/ fame, but also in general), Mac
| happily lets you run most things directly from the DMG
| without "installing", GNU/Linux _tends_ to favor going
| through the package manager but lots of people just build and
| run from source and there 's absolutely nothing preventing
| you running a static binary in place. Everything most
| certainly does not need an installer, though I grant there
| are sometimes _benefits_ to having one.
| MobiusHorizons wrote:
| Why does it need an installer if it doesn't contain dll's or
| assets? Is that a technical requirement, or are you saying
| end users want an installer.
| solidsnack9000 wrote:
| One practical reason is managing the lifecycle -- upgrading
| the app, removing the app.
| akaij wrote:
| Not sure why this can't be accomplished by simply
| replacing or removing the executable?
| jeroenhd wrote:
| Replacing a running executable isn't possible under
| Windows (and probably some other systems); you'd need to
| spawn a second process that waits for your process to
| die, replace the executable, and then relaunch the
| application.
|
| Possible, but a lot harder than doing it the Linux way.
| glandium wrote:
| Actually, you can rename the executable, place the new
| executable, run the new one and make it remove the old
| one.
| spicybright wrote:
| You can, but personally I think having to seek out some
| website when there's an update gets old pretty fast. And
| updates are important for security reasons.
| akaij wrote:
| Not sure how updates are related to an installer?
| dataflow wrote:
| It's a bit like asking "Why do you need a phone book to
| store someone's number? Can't you just call people
| directly?"
| zasdffaa wrote:
| The comparison is fatuous. If your mates had names and
| there was a button on your phone, one for each
| acquaintance by name, you wouldn't need a way of looking
| them up.
|
| BTW I also worked on a small in-house system that was
| just a run-it-from-the-desktop install (aka xcopy
| install) and it worked perfectly. Boss insisted we needed
| a "proper" installer so I tried the installer-maker
| provided by MS. Jesus what a fucked-up mess that made of
| the whole process, a day of trying to get that working
| (while it sprayed guids and subdirectories everywhere and
| could't even uninstall what it installed) and I gave up.
|
| I also have a fun story of an MSSQL uninstall that went
| wrong on a live server.
|
| executive summary is that xcopy installs work very well
| IME.
| dataflow wrote:
| > If your mates had names and there was a button on your
| phone, one for each acquaintance by name, you wouldn't
| need a way of looking them up.
|
| Which you realistically don't, hence the point of the
| comparison.
|
| > executive summary is that xcopy installs work very well
| IME.
|
| The point isn't the initial install, it's the subsequent
| lookups (including update, uninstallation, etc.) when you
| have a bunch of programs to deal with. When you're
| dealing with 1 program, you can treat it like your pet.
| But when you're dealing with 50, you can't do that
| anymore. You need to realize you have cattle and adjust
| accordingly.
| zasdffaa wrote:
| > Which you realistically don't
|
| Phone numbers are nothing like programs. The comparison
| is false.
|
| > The point isn't the initial install, it's the
| subsequent lookups (including update, uninstallation,
| etc.).
|
| Well perhaps, but if you can delete a program by
| literally deleting the file, and update it literally by
| replacing it then you are onto a good thing - unix-like
| simplicity. Dependencies may be a problem, or not.
| dataflow wrote:
| > Phone numbers are nothing like programs. The comparison
| is false.
|
| That wasn't the comparison in the first place.
|
| Finding the _location_ of the program and its uninstaller
| is very much like an address or phone number lookup.
| Updating it is like updating an address book. And you
| need a database to maintain it all and find what you
| need, and something has to update that database. That 's
| one major thing an installer does.
| zasdffaa wrote:
| OK, I see what you're getting at now. Given my experience
| with horrible messed up installers though, I maintain my
| plea for simplicity.
| G4Vi wrote:
| It would be nice if you didn't need to start out with tons of
| ccflags and ldflags, but I'll point out you don't actually need
| to use the amalgamation header, alternatively using -isystem
| you can pass the libc/isystem directory to add the libc headers
| to the include path.
|
| Especially for porting existing projects, I recommend against
| using the amalgamation as sometimes including everything all
| the time causes problems.
| ElectricalUnion wrote:
| A target like Rust x86_64-linux-unknown-cosmo ?
|
| https://news.ycombinator.com/item?id=32260619
|
| https://ahgamut.github.io/2022/07/27/ape-rust-example/
| jeroenhd wrote:
| This is great, I must've missed it! Thanks for the link!
| jart wrote:
| There's so much great stuff going on in the cosmoverse that
| it's hard to keep track of it all! We recently started
| https://github.com/shmup/awesome-cosmopolitan for that
| reason.
| [deleted]
| j_leboulanger wrote:
| I tried on MacOS and it does not work (exec format error)
| diego_moita wrote:
| I suspect your CPU is Silicon (ARM based), not Intel.
|
| The binary code is for Intel processors. Silicon chips have a
| completely different instruction set.
|
| For this same reason Android, iOS and RTos (for embeded
| systems) are not included among the targets.
| theta_d wrote:
| Pedantry incoming: Intel processors are also made of silicon.
|
| "Apple Silicon" is just a way to say chips designed by Apple
| vs a 3rd party like Intel.
|
| The instructions are Arm vs x86. This has nothing to do with
| the underlying substrate of silicon.
| kelnos wrote:
| I know that I have a general bias against Apple, but it has
| generally annoyed me that Apple has decided to take a
| generic industry term like "$FOO Silicon" and turn it into
| a marketing title.
| andsoitis wrote:
| To add more color.
|
| There are two kinds of ARM licenses. One is for chipset
| designs (e.g. Cortex -
| https://en.wikipedia.org/wiki/ARM_Cortex-A) that you get
| fabricated to get your CPUs.
|
| The other ARM license is an ISA license. You get no chip
| design. All you get is the instruction set architecture but
| you have to design the chip yourself. That's what Apple has
| been doing.
| BeefWellington wrote:
| This highlights the ongoing problem of article titles needing
| to be eye-grabbing but usually inaccurate/misleading or more
| complex than a simple title allows for.
| sph wrote:
| It's a title, it cannot be a paragraph long to be
| pedantically clear and unambiguous in what to expect.
|
| "Website that lets you download a 1KB long executable that
| can be run on 7 _kernels_ and x86_64 architectures, but
| actually it's only been tested on Intel and will probably
| not work on Android even if technically it's still a Linux
| kernel, also Linux < 2.6 is unsupported so YMMV"
| BeefWellington wrote:
| My comment (which I could have made more clear) was
| intended to be responding to the idea of quoting the
| title and then claiming it's misleading.
|
| I agree fully with what you're saying.
| Folcon wrote:
| I had this also happen because macos now uses zsh as the
| default shell and this approach is bash compatible.
|
| So you needed additional steps for macos. Not sure if that
| has been recently resolved?
| ok_dad wrote:
| If it's a zsh problem, you need to do something like:
| bash -c './redbean.com'
|
| or whatever your executable is called. ZSH is doing
| something incorrectly that prevents running these binaries.
| alganet wrote:
| There is a fix:
|
| https://github.com/jart/zsh/commit/94a4bc14bb2e415ec3d10cf7
| 1...
|
| Not sure if it was merged.
|
| Her approach is not bash-only, zsh is the odd one out on
| this one.
| jart wrote:
| It was merged: https://github.com/zsh-
| users/zsh/commit/326d9c203b3980c0f841... We patched fish
| too! Plus NetBSD sh and FreeBSD sh.
| _joel wrote:
| Will it run via rosetta?
| paulclinger wrote:
| Yes, there have been several recent changes to make
| Cosmopolitan executables run under Rosetta.
| edualm wrote:
| Works for me both under rosetta and native arm64 (macOS 12.2.1,
| M1 Max) - both by double-clicking the executable and using zsh.
|
| Only thing I had to do was rename the file to open it in Finder
| first because of gatekeeper requirements. arch
| -x86_64 ./hello2 hello world ./hello2
| hello world
| pdimitar wrote:
| Justine's work on all this has been hugely inspiring and a big
| breath of fresh air in an area that always kicks the can of
| reducing final binary sizes down the road.
|
| That's one of my very few gripes with Rust: compared to what Zig
| / C / C++ can produce, Rust's release binaries are quite huge.
| There's likely a lot of possible work to be done in the area of
| tree shaking and generally only leaving in what's actually used
| in the final binary. I hope this becomes a priority soon-ish.
| jart wrote:
| Rust adopted Node's quadratic dependency model, so Rust
| binaries are going to be O(n^2) larger and tree shaking isn't
| going to help unfortunately.
| pdimitar wrote:
| Why wouldn't it help? Surely this (and others) method do
| static analysis on what's actually used in the final program,
| no?
|
| Example: you use a crate with 13 functions. You only use 1
| but it depends on 2 others in the same crate that don't
| depend on anything else. Why shouldn't the end result only
| compile 3 of the 13 functions?
|
| Or maybe I am misunderstanding or I am badly informed (not a
| compiler / linker engineer so I'm likely with naive
| assumptions) -- apologies if so.
|
| I understand it's not easy, I am just a bit surprised that
| Rust's team is not chasing this a bit more aggressively,
| let's say. It puts a slight stain on an otherwise excellent
| project.
| jart wrote:
| Well it helps, but it'd be like spooning water out of a
| bucket when a faucet is pouring more into it. The NPM
| dependency model solves the diamond dependency problem by
| schlepping in multiple versions of the same package. C /
| C++ / Java (and I assume Zig too) require a single version
| of any given package. The way Rust and NPM do things adds a
| whole dimension of complexity to what needs to be shaken.
| It's sort of like a devil's bargain because it helps their
| ecosystems grow really fast, but it creates a lot of bloat
| over the long run. Rust is still relatively new so binary
| sizes are still pretty good compared to what we might
| witness in the future. So enjoy the golden age of Rust
| while it's golden!
| fsiefken wrote:
| It would be an interesting exercise to use executable compression
| on the fat binary to make it less fat that also transparently
| runs on the same 7 operating systems.
| chrismorgan wrote:
| Previous discussion a year and a half ago:
| https://news.ycombinator.com/item?id=26103769
| dang wrote:
| Thanks! Macroexpanded:
|
| _How Fat Does a Fat Binary Need to Be?_ -
| https://news.ycombinator.com/item?id=26103769 - Feb 2021 (67
| comments)
| rocqua wrote:
| Title seems wrong. I think this was intended to be "12 Kb
| executable runs natively on 7 operating systems". The HN
| suggestion of copying the article title would be: "How Fat Does a
| Fat Binary Need To Be?"
| unwind wrote:
| I believe HN filters out numbers at the start of the title.
| chrismorgan wrote:
| When HN mangles your title, you can restore it to sanity by
| editing the item: it only changes it on creation, not
| edition.
| moffkalast wrote:
| I wonder what's the reasoning behind that, it sounds pretty
| braindead.
| capableweb wrote:
| Filtering "listicles", articles with titles like "6 Secrets
| to Achieving Work-Life Balance", "23 Amazing Moments From
| The Harry Potter Movies", "5 Steps to Booking a Cheap
| Flight Online" and similar.
| moffkalast wrote:
| But what if number 4 shocks you? /s
| dang wrote:
| Yes, but the original title shouldn't have been rewritten in
| the first place since it was neither misleading nor linkbait
| (from https://news.ycombinator.com/newsguidelines.html: "
| _Please use the original title, unless it is misleading or
| linkbait; don 't editorialize._"). I've fixed it now.
| tromp wrote:
| Minor nitpick: I'd prefer to see size denoted as 12kB (or 12 KB)
| rather than 12kb, where I have to wonder whether it means kilobit
| or kilobyte. Note that Justine has also worked on languages whose
| programs consists of bits [1].
|
| [1] https://justine.lol/lambda/
| pmarreck wrote:
| > In 383 bytes we've managed to achieve garbage collection,
| lazy lists, and tail recursion.
|
| wat
| titzer wrote:
| That bit-encoded lambda calculus is nuts!
| remram wrote:
| Also if I read "kb executable", I assume one kb. Just like when
| I read "backpack computer", I assume it fits in _one backpack_.
|
| It's 12 kB, aka 96 kb.
|
| The HN submission's title is not even the article's title,
| which is "How Fat Does a Fat Binary Need To Be?"
| ThePadawan wrote:
| As pointed out in
| https://news.ycombinator.com/item?id=32649569 , this is
| probably HN autoremoving numbers from the start of titles to
| combat blog spam titles like "12 reasons to switch to XYZ".
| [deleted]
| jart wrote:
| As you wish. kB for kibibytes.
| laumars wrote:
| That's more likely HN reformatting titles.
|
| HN auto-title cases submissions titles and removes any numbers
| prefixing the title string. So "7 KB" would be changed to "Kb".
| shrimp_emoji wrote:
| If you get a scientific education, the importance of clearly
| noting your units is drilled into you. Programmers with their
| non-STEM laxity smh :p
| mysterydip wrote:
| Can this be used for something that displays graphics? Or does
| the runtime size balloon with supporting different functionality
| on each system?
| ok_dad wrote:
| You can run a web app locally using https://redbean.dev/ and
| open it in a browser. That's the graphics support so far.
| jart wrote:
| There's also https://github.com/jacereda/cosmogfx We've been
| thinking about rekindling that effort at some point.
| ok_dad wrote:
| Heh, sweet. I love this libc.
| nudpiedo wrote:
| I am not an expert on the topic but red language achieves that
| with a 1MB self contained compiler, so I guess with some
| additional bloat should be possible (and a lot of work)
| avg_dev wrote:
| > Is the Cosmopolitan Runtime lean and mean like Go's 2mb Hello
| World executables?
|
| I laughed at this. I am a Go programmer, FWIW :)
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
___________________________________________________________________
(page generated 2022-08-30 23:01 UTC)