<OriansJ`>christianbundy: that is because people don't actually remember things but rather only stories in their estimated 700MB of organic data storage unit called a brain. Because they compress better and allow a higher novelty value to ensure better probability of storage. <OriansJ`>although I believe they were unfair to multiple languages in their metric as libc can be entirely portable but usually are not for performance reasons. There are recursively defined libc entirely written in portable C; they are just slower and require either a native C compiler or a proper cross-platform C compiler. <xentrac>by "portable" they don't mean "can be recompiled for a different platform" <xentrac>they mean "can be placed on a USB stick" <OriansJ`>and they missed the Heavy environment entanglement in all of the interpreters (save for python and Perl where they did correctly identify it) <OriansJ`>xentrac: I could place a FULL linux distro on a USB stick <OriansJ`>I mean another system usually is either x86/AMD64 or ARMv7l/AArch64 <xentrac>yeah, but if you copy just an executable onto a USB stick, and then plug it into another computer, the executable may fail due to not having the shared library versions it expects <OriansJ`>Assuming you are not mixing POSIX and Win32 and build staticly it works just fine. <OriansJ`>but that does ballon binaries to a degree <OriansJ`>Guix of course really helps with the portable binary tars <OriansJ`>and I don't know of any packages in Guix that don't work when built for export and most of those languages are in Guix <xentrac>Right, but you can't assume you build statically. That page is written specifically to identify which language implementations are capable of building statically --- more generally, building self-contained executables which depend on nothing from their natal environment. <xentrac>Not just libraries, but also interpreters, data files, and so on. <OriansJ`>xentrac: well dynamic binaries can never be assumed to work because the kernel's loader implementation can ignore or violate all of your assumptions <xentrac>sure, you aren't avoiding the dependency on the kernel <xentrac>(I don't think he's talking about building bare-metal executables that can run without an OS) <xentrac>on another topic, I think there are things in the standard C library that can't be written in portable C. va_start, exit, and longjmp come to mind ***terpri__ is now known as terpri
***terpri_ is now known as terpri
***edef_ is now known as edef