But they give instructions like

cd downloaded_program
make install

This creates the ELF that is needed, and probably some .so files.

Why not put those inside a zip file for download, like with windows apps? Is there any reason why they need to be compiled by the user?

  • 18
    that is how source code is distributed. you tagged this with ubuntu - have you tried the apt stuff?
    – mikeserv
    Nov 27, 2015 at 0:58
  • 11
    Ubuntu : The 40,000 most common programs : $ sudo apt-get install [name] . The more rare software : Some must be built from source with {cmake .. && make, ./configure && make, waf, scons, etc. ~10 build options}. Nov 27, 2015 at 1:03
  • 6
    You have three Windows© versions, and ~100 "Linux OS" versions. Impossible to maintain and store more than the (40,000) most common programs. Nov 27, 2015 at 1:11
  • 35
    this question is just wrong. most software IS distributed in binary format, typically in .rpm or .deb or .tgz packages. The source is also distributed for those who want to compile it themselves or examine it or modify it, or package it for one or more distros. Nobody uses .zip for distributing binaries on linux because .zip files do not support essential information such as user, group, and permissions for the files they contain.
    – cas
    Nov 27, 2015 at 7:08
  • 2
    I have yet to need to compile any Linux program that I've wanted to run. Executables have always been available... so far. Nov 27, 2015 at 7:43

10 Answers 10


Let's analyse the factors...


DEPENDENCIES ACCORDING TO PLATFORM: There are some issues that arise in an environment where developers are creating and maintaining several architecture-specific variants of an application:

  • Different source code is required for different variants — Different UNIX-based operating systems may use different functions to implement the same task (for example, strchr(3) vs. index(3)). Likewise, it may be necessary to include different header files for different variants (for example, string.h vs. strings.h).

  • Different build procedures are required for different variants — The build procedures for different platforms vary. The differences might involve such particulars as compiler locations, compiler options, and libraries.

  • Builds for different variants must be kept separate — Since there is a single source tree, care must be taken to ensure that object modules and executables for one architecture do not become confused with those for other architectures. For example, the link editor must not try to create an IRIX–5 executable using an object module that was built for SunOS–4.

  • Every operating system has its own linking management scheme and must prepare the ELF (Executable and Linking Format) file as it needs it.

  • The compiler will generate a build that is a sequence of instructions, and distinct architectures mean different instruction sets (Comparison of Instruction Set Architectures). So, the output of the compiler is distinct for each architecture (Ex: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola's 6800, MOS T 6502, and so many others)


  • If you download a binary, you can not be sure if it does what it says it does, but you can try to audit the source code and use a self compiled binary in your system. In spite of this, the user Techmag made a good point in his comment, auditing the code requires knowledgeable and competent coders to assess code and is not a safety guarantee.

MARKET: In this section there are a lot of factors, but i'll try to resume it:

  • Not every company aims to reach all the platforms, it depends on the market and the platforms popularity and what they want to sell.

  • Free software have the spirit of making software as widely available as possible, but it doesn't imply that the software is designed for every platform, it depends on the community who supports it.


Not every software is designed for every platform. Providing binaries for all the architectures and platforms implies to compile it, test it, and maintain it for all the platforms. That's more work that is sometimes just too expensive, and can be avoided if the user compiles it in its own platform. Also, the user will be aware of what he's executing.

  • 1
    I think this answer would be improved by being a bit more explicit about processor model differences - and how ~10 years ago, each Unix variant basically had their own. Linux wasn't the pervasive influence that it is today.
    – Sobrique
    Nov 27, 2015 at 11:22
  • @Sobrique: Or even mention processor model differences per se - 10 years ago there use to be more than the 2 types we have today and Linux ran on almost all of them (I myself ran Linux on PowerPC). It's still partly relevant today with x86, AMD64 (otherwise known as x86-64) and ARM. MIPS is still quite popular today among people who can manufacture their own chips because it's completely patent free by now.
    – slebetman
    Nov 29, 2015 at 14:05
  • Sorry for the delay! Thank you both! I added some references to cpu architectures, also i added a link to a comparison list. I don't want the answer to be so big. But yes, it's very relevant! Nov 29, 2015 at 14:54
  • 1
    The security comment implies that the reader/installer knows how to read and understand the code. Given that the shellshock vulnerability survived decades without being noticed I would respectfully suggest that is a somewhat false belief. It does allow for knowledgable and competent coders to asses code yes but it's not as much a real security deterrent as advertised. It might actually have the opposite effect. State and organized crime funded hackers are likely contributing code for all manor of open source libraries/projects these days in the hopes of planting the next shellshock opening...
    – Techmag
    Dec 1, 2015 at 21:15
  • You are right! I modified the answer for reflect that. I tried to not lose the focus on the main objective of the answer. Thank you Techmag! Dec 1, 2015 at 22:25

There is such a variety of platforms and software environments both *nix and other, that the software may be able to be run on, that allowing you to build an application (or library to use with applications) is the only realistic way to support as many combination of those components as a "good" software item does. Of course, licences such as the GPL require the source code to be available - so even if the software doesn't work properly it is usually possible (though it might be tricky to comprehend what is wrong and how to fix it) for the user or some third party to dive in and correct it even if the creator won't/can't/no longer exists to do so.

Distributing software as source code also allows independent verification that the software does what it claims to and does not do something nasty instead of or as well - which despite reducing the level of trust one has to have in the creator, actually enhances it!


First, your question is based on a flawed premise. Programs are distributed in compiled format!

The normal way to install software on Ubuntu, like on most other Linux distributions, and more generally on most Unix variants, is to install a package. On Ubuntu, you open the software center or some other package manager and browse the available software. When you select a package for installation, the binaries (if the package contains a program) are downloaded and installed on your machine.

By default, the package manager offers you packages made by the distribution maintainers. You can also find third-party sources of packages; Ubuntu offers PPA as a standardized way for third parties to offer packages.

Downloading the software from the author in compiled form is a last resort. You only need to do that if the software isn’t popular enough to be packaged, or if you absolutely need the latest version which hasn’t been packaged. Most people never need to do this.

When software isn’t packaged for a distribution, it’s often distributed in source form rather than in binary form. There are two main reasons why this happens often in the Linux world, but rarely in the Windows world. One reason is that the proportion of open source programs on Linux is much higher. Obviously, if a program’s source code is not available, the only form of distribution is a binary. The other reason is that the Linux world is much more diverse. Different binaries are needed for each set of incompatible library versions, which often means different binaries for each version of each distribution. Windows “solves” this by having each package author distribute the libraries they use along with the program (consequence: your computer stores many copies of each library, one per program that uses it; if a bug is fixed in a library, each program that uses it has to ship an update), and by releasing a new version of the operating system only every three years or so. Unix has much more diversity and much more timely bug fixing habits, and solves the library distribution issues by building different binaries for different distributions.


Linux runs on more than just one particular CPU platform. If you distributed ELF files (or any other kind of raw executable), there'd be a chance that some versions of Linux couldn't run the software. In the spirit of making software as widely available as possible, using the source code is preferred. For example, Linux runs on Sparc, Intel, AMD, ARM, and other types of processors.

If the ELF file targeted specifically Intel processors, for example, then other types of hardware couldn't run the software. ELF is platform independent, but the code it hosts needs to conform to a platform's machine code. You'll notice how many distributions have similar packages (e.g. _386 and _586 packages when it supports different processors)-- you have to install the correct ELF file to get the correct operation.

Similarly, if I decide to build a custom Linux version that uses different interrupts, linkers, etc, then I still need the source code to compile the code. Even if the source code doesn't have platform-specific build instructions, each platform is different and may not run an ELF from a different system.

  • Which is exactly why you'd probably be running 32 bit firefox just like many other programs on a "64 bit" windows OS whereas 64 bit linux usually runs a 64 bit application.
    – mchid
    Nov 27, 2015 at 10:21

The original reason for distribution as source certainly was platform diversity; the Linux community has continued that methodology both for that and for new, partially political, reasons.

Unlike e.g. Windows, Linux has historically never bothered to keep any ABI (application binary interface) stable across long periods of time - keeping the possibility to innovate on aspects like executable formats, library APIs, and support for new hardware platforms was/is considered more important.

Commercial operating systems achieve long-term application compatibility by being very disciplined about innovation; a new feature/software interface always needs to be added IN ADDITION to an old one - requiring two things to be maintained, and the price of changing anything after release needs to be considered very high. Alternatively, you can embrace the fact of planned application obsolescence together with anyone writing software for your OS (this is not hinting at MS but another OS vendor).

Achieving a long-term stable platform for software distributed in binary-only form (outside of a given Linux distribution) would be even considered undesirable by some elements of the Linux community. As an unapologetic user of both platforms, I am not saying that is good or bad; it is like it is.


In many cases (at least in the *nix world), the source code is the most portable version of the software. Having the source guarantees that the shared software will work on every platform that could possibly support it (which in many cases simply means POSIX-compliant). Releasing binaries only guarantees compatibility with platforms (both software and hardware) that those binaries are released for.

Consider that on windows, binaries are the most convenient and portable form for sharing software. Since compiling source is not part of the usual windows software distribution model, Microsoft has gone to great lengths over the years to ensure binaries work across multiple versions of their OS: http://www.joelonsoftware.com/articles/APIWar.html

  • 5
    Windows depends on the underlying architecture as well. ARM-enabled Windows apps don't run on regular laptops/desktops, and so on. That's the main reason why Linux has much better hardware support-- because code's written to be compiled on any platform that has a sane Linux implementation, while Windows depends on known types of hardware being present.
    – phyrfox
    Nov 27, 2015 at 10:09
  • If you build Windows/x86 then you cover 95% of the binary compatibility. That's pretty good. Whilst Linux/x86 is getting more common, we came from a world where you had a variety of big names with their own special processor architecture and Unix variant - that wasn't binary compatible.
    – Sobrique
    Nov 27, 2015 at 11:23
  • @Sobrique Where did you get that 95% figure from? Last time I looked there was 4 ARM CPUs for every 1 x86. This was a few years back, before everyone started using smart-phones with ARM processors. So if we assume that there are no other processors that that is 20%. Dec 23, 2015 at 0:14

Most Linux software is free software. By distributing the source code with some compiling instructions rather than binaries, you have the opportunity to review or even edit the source code before compiling it. This way, you can be very sure what the program actually does and that it is not harmful.


The main reason that I personally don't like just getting an executable of a program is because I like to first check out what the source code is actually doing (mostly because I just enjoy looking at others' code) but I know of several others who also check source code for malicious code.


A lot of answers have said that in most of cases, software are distributed in compiled format. I agree with this assumption. Nevertheless I see a case where distribute a software by its source is better than distribute it in compiled format.

I am not sure that it's true, but I imagine in the beginning of the Internet, because network bandwith were bad, it could be sometimes faster to distribute a software by its source than in compiled format. As code sources are only plain text, it's often smaller than the software in compiled format. So, distribute a software with code source seems to be a better way to share it, provided that users are able to compile it.


Aside from the fact that there are many unix systems that run on many different platforms, just consider the problems that Windows software faces from this distribution modal, even though they really only have to worry about one version of windows, and one platform ( the PC ).

Even with just the PC to worry about, there are still two architectures: 32 bit and 64 bit. If you notice, the vast majority of windows software simply ignores 64 bit and only ships 32 bit software, leaving you with sub-optimal software if you have a 64 bit system. Then there are libraries. One software vendor does not want you to get strange errors trying to run their program if you don't have the proper library already installed, so they just include the library with their program ( making the download larger, even if you already have this library ). A second program does the same thing, but with a different version of the library. In the best case, program B contains a newer version of the library that is backward compatible, so if you install program B after program A, things work, but installing them in the reverse order leaves you with the older version of the library and so program B breaks. Often times though, the library vendor makes changes that are not backward compatible and does not bother changing the name of the library, so no matter which order you install the two programs in, the first one will break. This is called "dll hell".

Sadly, to avoid this, most windows software has resorted to shipping all of their libraries in their own program directory instead of a shared directory, so each program has all of its own private libraries and will never share with each other, which defeates the whole point of dlls in the first place and you end up using a lot more ram and disk space and time downloading all of the duplicate libraries.

This is why open source software is published in source form, and OS vendors have come up with package managers that sort out the dependency issues and download only the precompiled binaries that you actually need, without duplicating libraries all over the place. This also deals with the fact that there are many different unix systems that run on many different platforms.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .