OSDev.org

It has been discussed lately whether proprietary or free software is the way to go. I am not going into that debate here because it would probably lock the thread. I would like to discuss about release formats albeit it is hard to completely avoid the proprietary aspect because binary releases are often associated with it. It goes without saying that source code releases might be seen as "nothing to hide" and binary releases as "full of malicious features". Good vs. bad. It is more challenging to favor binary releases because of this and the previously-mentioned proprietary aspect. However, I decided to try bringing up some thoughts.

I see several problems with source code releases. First of all, it is hard to have a well-defined end product. Depending on compilers used to compile the source code, the end product is somewhat fuzzy. This would often lead to "No warranty of any kind". If using binary releases, the end product is well-defined and this makes it more attractive to have a valid warranty. Everyone has exactly the same product on their hands.

Secondly, I think it is harder to control user experience. What does this mean? If I had a source code release, I would have to take care of quite many tool-chain related issues. Does a user have knowledge to do the compilation? Does a user have proper tools installed on his computer? If having any problems, users are likely to abandon the product before they actually run it. The important first impression is lost if users have to struggle with the build process.

These two points are quite obvious and not very interesting. What I would really like to bring up is the development process. If we had the source code release, it means that we would have a tool-chain (e.g. configure & make) that is able to build everything in a user-friendly way. If we do not have a source code release, a programmer is able to do the build process in a way he/she wants. There could be some special tools for making the build. The real advantages come out when we have, for example, an OS project that consists of several modules (e.g. microkernel design). It would not be necessary to have a connected source code tree. It would be easier to cooperate with other developers if it is not necessary to worry about building everything at once. All could have their own build systems with bells and whistles. A well-defined binary interface between modules is the only thing that matters. The end product, an OS, is just a distribution of independently developed modules and making the distribution is another project in itself. There could also be custom tools used for doing it.

Of course, this post does not make much sense. I just noted a couple of things down.

If using binary releases, the end product is well-defined and this makes it more attractive to have a valid warranty. Everyone has exactly the same product on their hands.

Everyone does have the same product, but this is not the unalloyed advantage that you imply. Unfortunately, everyone has a different hardware configuration and a different software configuration. Hence the same product does not always work properly, if at all, on different configurations. With binary distribution it is almost mandatory to use statically linked binaries.

Secondly, I think it is harder to control user experience. What does this mean? If I had a source code release, I would have to take care of quite many tool-chain related issues. Does a user have knowledge to do the compilation? Does a user have proper tools installed on his computer? If having any problems, users are likely to abandon the product before they actually run it. The important first impression is lost if users have to struggle with the build process.

Whilst that is true it is not that difficult to overcome. A well written install script can check these things and install required dependencies or just inform the user what they need to do. On the other hand, it is (IMO) much more difficult for a binary to do this unless it is highly modular and contains a lot of redundant data.

Personally I prefer the source code approach, which can produce a more optimized binary that is guaranteed to run on the particular hardware/software combination. I have suffered intense frustration trying to get some binary distributions of software to run on Linux when they support only a particular, small subset of distributions. Sometimes it works, sometimes it doesn't. And this ignores the different package formats available. One of the joys of FreeBSD, adopted by Gentoo Linux, is the ports system.

People just want things to work. The tools we build are not intrinsically valuable to others, it's what these tools allow users to do that is valuable. Hobbyists aside, few people have the time to download, build, and install source distributions. The older I get the more I want to optimise my time and work on interesting problems. I don't see the extra work with source distributions as a good use of my time unless I need to see the code. Frankly, it's a relatively unproductive use of a programmer's time.

I once worked on a binary compiler that took a executable binary for a proprietary chip and translated it to work on a COTS microprocessor. The company had an established base of products based on the proprietary chip and a newer line based on the COTS microprocessor. The system with the COTS microprocessor held the compiler on disk and invoked it whenever the binaries were updated. The customers bought/rented the functions implemented by the binary and the company just made sure that the binary worked on their systems. The customers didn't care how it was distributed, they just wanted the functions. This simplified productification(*) for the company which, no doubt, saved a lot of money

EDIT: As the OP pointed out, there can be a problem with different compilers. Even if all compilers used conformed to the language standard, some programming languages have their semantics defined in natural languages which can leave the standard open to interpretation.

*) Yes I know not a real word but it's the best translation I can come up with.

iansjack wrote:With binary distribution it is almost mandatory to use statically linked binaries.

This isn't such a bad idea if you're releasing a product you are expected to support. The uniform code base provides greater determinism which in turn makes fault finding easier.

The uniform code base provides greater determinism which in turn makes fault finding easier.

That convenience comes at a cost. Apart from the obvious larger footprints both on disk and in RAM, static binaries are also less flexible. Say a binary depends upon a particular library and that an improvement (most importantly a security aspect) is made to that library by the OS publisher. Then every program that uses that library needs to be recompiled to take advantage of the change and all those recompiled binaries have to be distributed. With dynamically linked programs you just update the dynamic library - everything else follows automatically.

But, as this is a site developed to OS development I was really looking at the OP from that point of view. Users of hobby OSs tend to be sophisticated enough (IMO) to run a makefile.

Hobbyists aside, few people have the time to download, build, and install source distributions.

Isn't that our target audience?

iansjack wrote:Users of hobby OSs tend to be sophisticated enough (IMO) to run a makefile.

The requirement of running a makefile would also make sure that those OSs are, and will be, hobby OSs.

iansjack wrote:I have suffered intense frustration trying to get some binary distributions of software to run on Linux

Linux is not very friendly to binary distributions of software. However, that does not mean others could not be. If we had good standards (e.g. what basic libraries / system calls / services are available), it would be possible. Windows does this more or less good. Of course, we should remember this: "Binary" could also mean byte code that is architecture-independent.

It doesn't have to be a requirement, just a possibility. Probably the best solution is to release binaries for common configurations and source for other platforms or those who want to compile.

Works for FreeBSD and Linux, and I wouldn't describe them as hobby OSs. I agree that if you are aiming for the masses it is unrealistic to release source code alone. And if you are aiming not to be the next evil empire it probably pays not to release binaries alone.Sometimes "less". And I'm not convinced that the majority of posters here are aiming to emulate the Microsoft model.

iansjack wrote:But, as this is a site developed to OS development I was really looking at the OP from that point of view. Users of hobby OSs tend to be sophisticated enough (IMO) to run a makefile.

Hobbyists aside, few people have the time to download, build, and install source distributions.

Isn't that our target audience?

To be honest I had cast a wider net.

If you want to make me look at your hobby OS, then I want the source to be available so that I can look into the parts that look like an interesting read, and binaries available because I can't be bothered to set up a build environment, possibly with crosscompilers and all that stuff.

If you play a trick on me and the source and the binaries don't actually match, the binary can't do anything bad because it runs in its own VM. So the worst thing that can happen in the context of trying out a hobby OS wit binaries is that I notice that the observed behaviour doesn't match what the source I read says, then I'll be annoyed and just delete your image again. (Your Makefile, in contrast, could be doing nasty things on my host, so that's another reason not to run it.)

Source or Binary?

Wanna become the next Bill Gates?
Distribute ONLY binaries.
Wanna become the next Linus Torvalds?
Distribute ONLY sources. (Does anybody know where do they post pre-compiled builds?(Linux 3.12) don't know how they get that compression rate. I hate hand-compiling it.)
Wanna become a normal coder?
Distribute both of 'em.
I think a coder must distribute of them, binaries for people who want to try out
your program or OS, you may never know some normal people who are not asm or C dudes,
might checkout your OS or program, so they would be comfortable with a pre-compiled version,
on the other side, there are ASM and C dudes, who know how to link,compile and test, give them
the sources.

iansjack wrote:Probably the best solution is to release binaries for common configurations and source for other platforms or those who want to compile.

I agree. However, that does imply that source code must be user-compilable. I do know that this is usually possible (e.g. applications written in well-known languages & compilers freely available).

If source code is not released, all the troubles that we have when making it easy to compile the whole application at one go disappear. If we had splitted an application into different modules, they could use totally different toolchains, programming languages, etc.

Kevin wrote:If you want to make me look at your hobby OS, then I want the source to be available so that I can look into the parts that look like an interesting read, and binaries available because I can't be bothered to set up a build environment, possibly with crosscompilers and all that stuff.

Now we are in business. It would be possible to have an official binary release and source code for viewing purposes only. It means that I do not support any toolchain related things (e.g. build scripts) but just plain source files if someone would like to look at them. This would be a really nice and clean release format.

Perhaps the difference between us is that you guys are confident that you can supply perfect binaries that will work on any configuration and will support all the features the user wants, and none that he doesn't want. I like the idea that a user can modify my code in whatver way they see fit, and can configure the compile to produce a binary suited to their exact needs. And I like to think that many users are capable of doing that.

I'm a big fan of Open Source.

Perhaps the difference between us is that you guys are confident that you can supply perfect binaries that will work on any configuration and will support all the features the user wants, and none that he doesn't want.

Great!
To be honest, I never thought of that.

Just as a matter of interest, do you guys who are advocating binary-only releases use a cross-compiler to produce your OS binaries?