Binary vs. source code

[Combuster]

By having the source code they can more quickly point out where the location of the error and if they didn't have the source code they would have been almost blind and wouldn't understand what's going on.

it can be done with a good system of logging

And the increasing lack of rare earth metals can be fixed with a fusion reactor. Tell me, how much more cost-effective is your plan for the hosting company?

[Kevin]

from what i read from linux dev mailing list, the policy of linus torvald is to favor the making sure that already working code keep working, rather than adding support for new things that could break already working feature, or impact them negatively , or could be detrimental in configuration that already considered to works

And this is the only sane thing to do.

so it still need to have an idea of the big picture, and to follow a bit development history, and policies, to be able to really make meaningful contribution , and need to be a bit involved in the global development community, and project history etc which still require more minimum time involvement that is not necessarily wanted by most people who will use the software

The point is that you can just ask someone who does have the big picture. Contact them before you do the coding, or send out an RFC patch to them, and they will tell you what you need to consider. Even though you take their time for replying to your questions, if you read and respect their answers, they still save time by not having to implement it themselves - which means that it's more likely to happen.

Software often doesn't offer exactly what you want, even though that would be the optimal case. So this is a given. In closed source software, you either take what's there or you leave it. When you get the source code, you can instead change the code to make it work for you. And people do it. This is an advantage for them, because the scenario to compare to is not closed source software that already has the functionality from the start, but closed source software that doesn't have it and can't be changed to get it.

[Antti]

If we had to rely on the authors of the software to provide binaries for every niche platform these non-mainstream ones would never get off the ground. As it is, anyone can produce a version of Apache to run on whatever OS they are using on their Pi (with maybe a little hard work). If I had to wait for the Apache Foundation to release a binary of Apache to run on FreeBSD 10 on a Pi then I would still be waiting.

If we had a bytecode executable and a well-defined specification for an interpreter and environment, porting the executable to a new system could be elegant. What you described in your post is not optimal for that matter. It also requires that you have a compiler that is able to compile the source. In practical terms, your words make sense but the perspective is so Unix-oriented.

If we ended up favoring source code, we should do that properly. Like in the way we discussed in another thread. Well, it was not a serious reference...

[iansjack]

What you described in your post is not optimal for that matter. It also requires that you have a compiler that is able to compile the source. In practical terms, your words make sense but the perspective is so Unix-oriented.

Apache and MySQL, to take just two examples, have been ported to Windows. I do not believe this would have happened if the source code were not easily available. I suspect they could also be ported to other non-Unix systems with little difficulty. There is certainly more chance of that happening than waiting for the Apache Foundation or Oracle to provide binaries.

[Thomas]

By having the source code they can more quickly point out where the location of the error and if they didn't have the source code they would have been almost blind and wouldn't understand what's going on.

it can be done with a good system of logging

And the increasing lack of rare earth metals can be fixed with a fusion reactor. Tell me, how much more cost-effective is your plan for the hosting company?

Actually h0bby1 is right in some sense , you can pretty much figure out what is going on from the crash dump. I knew engineers who could re construct the source code almost instantly by just looking at the dump. That being said my way of debugging is different , I meditate on the source and see what scenario resulted in the crash. Depending on situation and luck either of the methods can be effective. Having the source code with you definitely is an advantage!.

--Thomas

PS : I used to be maintenence engineer for an OS d( had 0 bad patches or fixes for my entire career ~ 3 years )

[h0bby1]

also it depend if by "binary" you mean "executable", or if it's more the source protection that is at stake

if the final product is a script, the source is still available, but there is no 'compile stage' involved, and the script can be directly executable on the target machine, without involving any special tool outside of the interpreter

or if the goal is to hide source code , for commercial purpose, even releasing non protected binaries is not totally protecting the algorithm, if you consider the whole thing of application cracking, or trainer for games, or even stuff like diablo hack, even binaries can be modified, read, tweaked, specially in the old day in amiga where most of the application were programmed in assembly, even release the binary was not so much hiding the source code, the whole issue of protecting patented or 'secret' algorithm can be much more complex than the issue of release source code or not, and only legal protection can really be meaningful, or need to have some kind of crypto or other protection in the binary if the source or algorithm must really be hidden at all cost without considering the commercial/legal aspect, because anyway if it's for commercial purpose, if your algorithm is legally patented, it still prevent any competitor to commercialize product derived from it even if the source are available, or that he can 'reverse engineer' the binary

but there can be also an objective behind open source that is more on the side of research/student thing, linux was first made to provide some free unix for student, and open source can also be seen in term of open research, and community development, but it doesn't prevent to also release the product in binary form for the end user, it's a development method but it doesn't prevent in itself to prefer the binary form as end product, or to make in sort that anyone who is not a developer doesn't have to deal with source code at all

if it's just for 'porting', if you exclude the whole issues of binary executable format, and cpu type, and also exclude the possibility that users will modify the sources which should not be the case anyway for users, if the source release is only for blind automatic compiling , the issue then is mostly to enable some conditional compilation to match the API version present on the system, or to enable certain code path, which could also be done at runtime or during setup stage with detection, even if it can increase slightly code complexity and increase a bit the size of the binary release, if the target system still expose a well defined API, the binary program should be able to detect it, and adapt the imported symbols, version of API, and code path at runtime, or setup time, many software do this, like video codecs, or even 3D engines, a single binary can also be made to run in optimal manner on different configurations or different version of system API , without the need for a system specific compilation to select the good code path

[h0bby1]

By having the source code they can more quickly point out where the location of the error and if they didn't have the source code they would have been almost blind and wouldn't understand what's going on.

it can be done with a good system of logging

And the increasing lack of rare earth metals can be fixed with a fusion reactor. Tell me, how much more cost-effective is your plan for the hosting company?

personally, ideally i prefer to have a well documented software, with good error logging, that is well tested in which context it's supposed to run, what functionality it's supposed to support, and that test everything to prevent crash with meaningful error feedback, rather than to have to dig on the source to know what's going on when there is a crash

but it can help in some case, but normally you only need sources if there is already somehow a bug in the software, and it's the thing that i often find a bit lame with that view of open source, is that developer expect that end user can fix themselves minor bugs, or expect that the user will be able to read the source code and tweak it to their need, and it often give me an impression of 'non finished' development

in the same time, it's also what make open source efficient, because it's ever going development process, there is never a 'final version' of open source project, it's made to be constantly evolving, branching, forking, being fixed, and redistributed, and it can allow for the software to be constantly adapted to new situation, instead of relying on release a single version in a form that is not made to be modified at all, but tested to support some well defined but restricted set of feature until there is a next release if there is a bug, or a lack of support for a particular configuration

[Antti]

I do not believe this would have happened if the source code were not easily available.

You are right. Source code releases will beat plain binaries if we had to to choose between these two. At least we got an interesting thread and debate.

I would still suggest that OS developers should invest in binary releases (e.g. an ISO image) if they want to have real users. It is just an extra feature to have the source available. The binary release should not be a second-class citizen but a finely-polished and up-to-date product. If we just said "checkout my github, build a cross-compiler, study build scripts, etc.", it would drive away many potential users. Actually, it would drive away the users wanting to actually use the system. Only programmers would try the system and they would probably not use the system but just check what it is.

[Kevin]

personally, ideally i prefer to have a well documented software, with good error logging, that is well tested in which context it's supposed to run, what functionality it's supposed to support, and that test everything to prevent crash with meaningful error feedback, rather than to have to dig on the source to know what's going on when there is a crash

That's a fallacy, you're mixing up two entirely different things.

Hiding the source won't make the crash go away. You'll certainly agree with that? If there is no crash in the first place and you're happy with the functionality (i.e. don't need any extensions), then for you there's no difference between having the source and not having it. However, if there is a bug or you need that added bit of functionality, without having the source you're completely dependent on the author to make the change. When you have the source, you can still ask the author to make the change; but you also can do it yourself, as an additional option.

Having the source doesn't take anything away from you, but only gives you additional options, so why could it be a bad thing?

[h0bby1]

personally, ideally i prefer to have a well documented software, with good error logging, that is well tested in which context it's supposed to run, what functionality it's supposed to support, and that test everything to prevent crash with meaningful error feedback, rather than to have to dig on the source to know what's going on when there is a crash

That's a fallacy, you're mixing up two entirely different things.

Hiding the source won't make the crash go away. You'll certainly agree with that? If there is no crash in the first place and you're happy with the functionality (i.e. don't need any extensions), then for you there's no difference between having the source and not having it. However, if there is a bug or you need that added bit of functionality, without having the source you're completely dependent on the author to make the change. When you have the source, you can still ask the author to make the change; but you also can do it yourself, as an additional option.

Having the source doesn't take anything away from you, but only gives you additional options, so why could it be a bad thing?

but considering the product as non open source, it make it more important to have something that can run totally without problem on any platform, whereas with the open source philosophy to think user will anyway change the source to fit their need, or tweak the thing if there is a minor bug, or the thing doesn't work as expected, leave more room to be more lazy with minor bug tracking, or working toward comfort of use and installation, it can go in the direction to require more work from the end user and more involvement from users with the development team, even only to have it functioning as it's supposed to

it's not either the goal of an application to have users to do any change in it themselves, unless it's some kind of research project and users are more 'code source users' as developers more than user who only want to use the function that the program provide, without having anything to do with source code

if you are in a bug fixing perspective, then you see yourself as developer, and not as end user

it's all in the policy if the developers expect user to have something to do with the source in a normal use or not, and even if you have the source, it doesn't mean you'll necessarily to be able to understand and fix the problem either

if the source is indeed seen purely as optional in case you want to help with development, or fixing stuff, or know how it works for your own education, it's not the same than releasing it as source because of inability to provide a fully workable binary that would work as expected on all the intended configurations

[iansjack]

@h0bby1: I don't wish to appear rude, and I'd hate to be seen as a grammar nazi, but would it be possible for you to apply the accepted conventions for written matter. Capitalization, division into sentences, use of punctuation, would help to make your posts readable. As it is I find my eyes glazing over before I reach the end of the first rambling, unstructured phrase.

I'm sure that you have interesting points to make but it is difficult to read far enough to appreciate them.

[Kevin]

but considering the product as non open source, it make it more important to have something that can run totally without problem on any platform,

In practice: Run good enough that users don't switch away, on a single platform that happens to be the most important one.

if you are in a bug fixing perspective, then you see yourself as developer, and not as end user

Indeed, having the source around allows me to switch to a developer role if I want.

it's all in the policy if the developers expect user to have something to do with the source in a normal use or not, and even if you have the source, it doesn't mean you'll necessarily to be able to understand and fix the problem either

Right, it's a matter of developement/release policy rather than the question whether you can get the source or not. Hiding the source doesn't magically give the authors more resources for testing, documentation and polishing.

Now your claim seems to be that open source software generally has a policy of "let's provide something broken as a release and let the user fix it". I think such a bold claim needs some evidence to support it. My naive view is this: I'm running tons of open source software every day, and I haven't contributed to more than a handful of them. Apparently it works quite well even without me fixing stuff each morning before I boot the system. This seems to be a very clear contradiction to your statement.

if the source is indeed seen purely as optional in case you want to help with development, or fixing stuff, or know how it works for your own education, it's not the same than releasing it as source because of inability to provide a fully workable binary that would work as expected on all the intended configurations

I think you're the only one in this thread who is talking about inability to provide binaries (and only binaries). The rest is talking about whether and why it's better to have the source published (and generally assuming an open source license) even though you could do only binaries.

[h0bby1]

but considering the product as non open source, it make it more important to have something that can run totally without problem on any platform,

In practice: Run good enough that users don't switch away, on a single platform that happens to be the most important one.

if you are in a bug fixing perspective, then you see yourself as developer, and not as end user

Indeed, having the source around allows me to switch to a developer role if I want.

it's all in the policy if the developers expect user to have something to do with the source in a normal use or not, and even if you have the source, it doesn't mean you'll necessarily to be able to understand and fix the problem either

Right, it's a matter of developement/release policy rather than the question whether you can get the source or not. Hiding the source doesn't magically give the authors more resources for testing, documentation and polishing.

Now your claim seems to be that open source software generally has a policy of "let's provide something broken as a release and let the user fix it". I think such a bold claim needs some evidence to support it. My naive view is this: I'm running tons of open source software every day, and I haven't contributed to more than a handful of them. Apparently it works quite well even without me fixing stuff each morning before I boot the system. This seems to be a very clear contradiction to your statement.

if the source is indeed seen purely as optional in case you want to help with development, or fixing stuff, or know how it works for your own education, it's not the same than releasing it as source because of inability to provide a fully workable binary that would work as expected on all the intended configurations

I think you're the only one in this thread who is talking about inability to provide binaries (and only binaries). The rest is talking about whether and why it's better to have the source published (and generally assuming an open source license) even though you could do only binaries.

well i'm just exploring the reason why one would want to release sources of his product, if it's not intended to developer audience, and just for user, the interest to have the source is pretty nill, and still most open source project are released as source code, even if they don't target potential developers, which doesn't provide clear interest for the user

it depend also kind of open source software you use, but i see people getting into linux often, and you never get something that work 100% with all multimedia devices, printers, scanners, webcams, all functions, and soft who works like a charm like that straight out of the box, it's not rare that it can take a week or more to have everything well set up, and it often involves still having to tweak some things, due to bad compiling environment, bad dependency, because of so many version of the binaries can be potentially present, on closed source software who only release binaries, there is not this problem as all the systems will have a well defined version of binary files, so you know exactly what to expect from the binaries present on the system

it's not that it's necessarily broken software, but the policy to say 'i give the source for that people can fix it' is still a bit lame on the border compared to 'i give a thing that work for that you don't need to modify the source yourself' , but it's not necessarily the only reason why one would want to make a project open source either, but it can still be part of the motives, and often it come down to let user adapt the software to their particular system, instead of releasing already adapted package ready to run without anyone other than developers need to have the sources

but yeah after it can be quicker from a developer perspective to just give away sources with a doxygen doc, instead of really making manuals, testing, error checking and report, and rely on third party to fix bugs or make it work on their system for their particular use from the sources, instead of anticipating all case for that end user, or sys admin have less work to do to install and use the software

[Combuster]

well i'm just exploring the reason why one would want to release sources of his product, if it's not intended to developer audience, and just for user, the interest to have the source is pretty nill, and still most open source project are released as source code, even if they don't target potential developers, which doesn't provide clear interest for the user

And yet, the vast majority of all Linux software is downloaded in binary form, rather than source form. By end users. Even if the original developer only released source code. Something somewhere must be going horribly wrong...

In other words, you're argumenting based on a problem that doesn't even exist.

[bluemoon]

you can pretty much figure out what is going on from the crash dump. I knew engineers who could re construct the source code almost instantly by just looking at the dump.

With decent crash dump, for developer with the same version of binary and debug infos, they can relaunch the application in the debugger right at the fault point and stare on the break point from the source window.

However, sometime the breakpoint / crash point may be very far away from the real bug.