Slashdot Mirror
Why Are Binaries And Screenshots Good Things?
QuantumG asks: "I recently got into an argument with an open source project leader over wether or not releasing precompiled binaries is a good thing or not. He was adament that if potential programmers had to download the pre-alpha source code they would be more likely to take up an active part in programming than if they could just grab a binary. I thought it was important to make it as easy as possible to show the current state of the project to new recruits so they could see what has been done, what needs to be done and what could use work. I feel the same way about screenshots. What does Slashdot think?" Binaries are definitely important. Remember, programmers aren't the only ones who would like to look at your code and see what you are doing, and it's not right to expect them to compile code that may not be easy to compile. Of course, there is a (debatable) point in the software lifecycle where the software is deemed "mature" enough for binaries. What do you all think about this issue?
But for alpha software, sure, make them compile it. If it doesn't compile it shouldn't have even been released to alpha...
-E
Send mail here if you want to reach me.
(there's a phrase you thought you'd never hear)
I haven't browsed at -1 for a couple of months, but there used to be someone who would regularly post quite informative and genuinely relevant URLs, except that they were the body of a goatse.cx target link. Brilliant!
Sometimes I was tempted to moderate him up. (OK maybe her, but somehow, I doubt it)
I just couldnt decide between +1 -informative or +1 -funny.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
It's potentially dependent on what OS you're running; it's not limited on some OSes, and may be limited on others. Try a limit command in the C shell or compatible shells, or ulimit -a in the Bourne shell or compatible shells (the latter may not work on some OSes).
In a program, put in a setrlimit() call that sets the RLIMIT_CORE limit to RLIM_INFINITY (if the OS for which the program is being built supports setrlimit() and RLIMIT_CORE - if it doesn't support them, there's probablly either no limit or a limit that can't be changed; if it doesn't define RLIM_INFINITY, try a maximum-sized integral value).
From the command line (i.e., if the debug version of the program doesn't work around it), use the limitulimit (Bourne shell and compatibles) command. (If they don't let you get or set the limit, there's probably either no limit or a limit that can't be changed.)
I try to write readable code and use rather long identifiers in general. I find that my comments explain why I did something rather than what I did.
Thanks
Bruce
Bruce Perens.
I know it will take a time, but the time does not seem to be a problem. On Windoze people are willing to double-click something and wait forever for it to do things like download from web sites, so compilation time is not a problem.
Obviously this "installer" program is a complex pain to write and there would have to be a standard.
As for screenshots, I definately want to see them, they help a lot in figuring out just what a program does.
I have *never* had a big problem compiling software for Linux. Yes, you have to read the damn docs, yes, you have to learn how to do certain things, tough...
Have you tried to compile ghostscript? It used to be a real pain in the ass. And ImageMagick? A PITA, too. Now precompiled binaries for both of those work very well. And yeah, I've compiled them both at least once (actually much more than once), and I'm not going to do it again. I'll just grab an RPM.
--
--
I don't have the time to get involved with everything. However, I do have the time to try out some binaries and see if I like the project. If there aren't binaries, I'm not likely to try it out (unless it's something I really, really need).
Anything that heightens interest is a GoodThing(tm). Binaries and screenshots do so.
There are so many projects out there doing much the same thing, that the binaries and screenshots become like marketing. Necessary evil, but useful nonetheless.
Regards,
-scott
Regards,
-scott
I have *never* had a big problem compiling software for Linux. Yes, you have to read the damn docs, yes, you have to learn how to do certain things, tough...
.02
Binaries are released quite often, especially for large projects (not just Joe Blow's software v.0012). Personally, I still prefer to use source tarballs b/c I can control EASILY where the programs will be placed. rpm --install xxx.rpm doesn't cut it...
The other big problem is packet management. There is absolutely no reason that we should have binary files in 100 different types of formats... If we are going to have binaries, release them as one method. I don't care what it is but come up w/soemthing.
Just my worthless
For instance, XFree86 servers, or Mozilla...
Lots of people wouldn't be able to, or want to,
deal with source-only distributions of these.
It's a HUGE job to build these things, and require
some outrageous massaging to do it.
Things that will compile in 30 seconds and depend
only on libc, that's very different.
-fb Everything not expressly forbidden is now mandatory.
As a Linux User of 4 years I vote for compiled Binaries. I cannot program worth a wit in C, I can hack my way through PERL and Python but C... no way. I have been using Linux for about 4 years, and love apt. Please release binaries if you want a large user base, and just source if you want just 'leet people to use your software. Its simple really!
Rule of Life Number 2: Remember, it can all go to hell at any minute. --Jimmy Buffet
Um, and I am one of those people; that is sort of my point. However, a lot of people like to have only one machine, or want to optimize the flexibilities of a machine. And there is some competition between OS's: yes, some are better at some things than others, but they are competing in a lot of fields and to think of that simply as "separate tools" that don't share a lot of functions is a bit naive. If it were simply a matter of what Linux was "good for," there probably wouldn't even be a Gnome or KDE - the very products imply an expectation to compete with Windows and MacOS in a lot of environments where they currently are not rivalled by the Unices.
I build almost everything from source on FreeBSD using the ports collection, because that's how I install new software. I've installed dozens of packages, and haven't typed 'gcc' or even './configure' once to do it, just the final step: make install. Trivially doable with a CGI script if I wanted to add a pointy-clicky front end to it. I think I have needed access to the source maybe a half dozen times, and actually changed something in there twice. I think apt can do the same, but it's not configured to by default. Even source RPM's are nicer than binaries for me, because although they still don't fix the manual dependency resolution problems (meaning some kind of semi-manual process to resolve them), they typically aren't plagued with glibc versioning problems (aka dll hell). With a decent front end, a user doesn't even have to know the package is compiling (e.g. said CGI that builds a port), just that the package tool seems kind of slow ... and their system is more stable.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Good new word - grabber. Some one that grabs programs...
Well, there is one thing that people may not be remarking. Many programs become popular not because the developer gets an eye on them but users tell so. "Oh there is this new XXXXX prog out there. I grabbed it and it seems cool. Yeah it is quite alpha but I think it's a good idea for this, this and this." And the developers, system integrators, sysadmins go after that program to see if it's worth a look.
Note I'm not talking about users/developers. I'm talking about people with nearly zero knowledge about programming. There is a growing horde of them on Linux. And there is a new class, small but ambitious, that tries to look around, more than most users do. Grabbers are a known class in Windows world. There is even a black Grabbers elite that uses ready exploits for their less ethical work. But Grabbers don't end here. They are a huge class, as important as hackers. And they are hugely varied. There is a special group of visual Grabbers. People that collect programs on 2D/3D graphics processment. And they are great collectors. Some of these archives go over the Gigs. These people may not be the front line of development. But they surely are one of the most important supply lines as they show where we should go.
Binaries are nice to see what stage some sort of alpha software is at. However, the biggest obstacle for me to download and look at source code is all of the additional libraries you need.
It's happen at least 4 times to me where I've downloaded CVS source to play around and spent hours trying to get the thing to work because it requires the CVS versions of libraries, and often this isn't documented.What's even more frustrating is that most of these programs don't really need the new features that badly.
I think that most of the people who would be able to make a useful contribution to a project will have very little trouble downloading and installing source. However, a lot of these people won't have the latest CVS version of gnome-foobar.
I'm not sure I see what is so difficult about:
./configure
make install
Which is about all it takes to install 95% of the stuff out there from source...
Don't blame a binary, blame a stupid user for downloading something from an untrusted site. Same logic goes when talking about why their are no virii for linux. It all goes into, "Only run what you trust", if you don't do that then you deserve what you get.
And as far as KDE goes, I really have no idea what you are talking about -- I just downloaded it and compiled from scratch and it was a) significantly bigger than linux-2.2.17 and b) took about 1.5 hours on a 500Mhz to build everything
This goes into my original point though, if you want to see what it's about use a binary so you don't have to muck with compilation. If you want to use something, compile it because you'll get the best product out of it.
Dacels Jewelers can't be trusted.
I like screenshots, good eye candy. Me and another developer who are working on different methodologies for gradients have shown back and forth about 5 different screenshots to see what has the best result.
Dacels Jewelers can't be trusted.
Use better terminology, you do not "hack" a binary. You corrupt it. It still has absolutely nothing to do with the argument of Binary Vs. Source -- the same thing can (and did happen) with source distributions, that was why your argument was absurd. It really is, saying binaries are bad because of the possibility of infection. Both are. That is my point.
And yes, it is KDE1 that I was referring to as KDE is still known as KDE1 and KDE2 referred commonly as KDE2. Yes, for those who don't want to dedicate an overnight compile for KDE2 should use binaries. As for myself, it's quite easy to write a shell script to recursively compile directories and check for errors and even start "xmms No_Satisfaction.mp3" on an error to wake me from my slumber.
Dacels Jewelers can't be trusted.
Binaries and screenshots are pretty essential if you want to sell someone on an idea. Even if you don't have a GUI you can still give some examples of input and output, especially if you're doing some complex shit that doesn't exactly stand out in your code. I hate looking at a project and seeing some vague descriptions and just some code in tar.gz packages. My friend and I have been working on similar hobby projects that do similar things so we decided to combine our codebase. Before sending him my code I commented the hell out of it and compiled on my handwritten notes and flow charts to the point where my mom could have picked up my code and finished the project. Unfortunately the code I got from him was just a mess of code with some commented out lines, just stuff that was broken or unneeded. This ishow I see a lot of open source projects distributed. Spaghetti alpha quality code with little or no documentation by the dude who originally started the project. I think more people would get interested in OS projects (as asserted in the original story topic) if more people would better document the development of their program. Binaries are a must because sometimes your code won't compile correctly on other machines. Screenshots (or at least some form of output) ought to also be included not only in the package but on the website. Give some good indications to outside observers about how well the project is coming along. You're also giving people a preview of what your program will look like. The people downloading your program are also going to be the ones using it, let them see the interface and get their opinions on it. The same goes for CLI programs, let people see how data will go in and how it will come out and take some comments about how you could maybe do a better job of organizing your arguments or keeping them easy to remember.
I'm a loner Dottie, a Rebel.
Example: Someone writes an HTML editor. If there are screen shots I can see if it is just a syntax highlighter or if it is a editor like Frontpage or Composer. If there are lots of them then I can see what features it has and how they define there UI.
This can even work with console apps that output data, like vmstat, where you can see what data it outputs.
Source Code: To me that is less importatnt. If it is in alpha I'd rather see a screen shot so I can see what is coming. Even after it is released I don't always compile from source. Rarely do I do that now. It usually offeres little benifits to compile from source and more headaches. If I find a bug then I'd likely email the author. This also depends on the size of the program and my time. When I used to have more time then I'd do more looking into the code, but now, I do less of that. I also have less problems.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
There isn't a large quantity of work involved with either, but it isn't interesting work. Once a developer has learned a quirky build procedure (perhaps through trial and error combined with frequent email and IRC queries), it's easier to just put up with the procedure than to make it more user-friendly.
--
send all spam to theotherwhitemeat@ropine.com
This is the most insightful comment on the page; I'm glad SOMEBODY gets what open source is about. Everybody else is hereby commanded to go read 'The Cathedral and the Bazaar'
I would say lack of binaries is not a problem, except for the fact that i can't even remember how many times i've gotten frustrated when i tried to run configure and it died requiring the development version of some or another widget set one minor release ahead of the one i have, and i go and get that and it requires headers from openGL even though it does _nothing_ 3d, etc... and by the time i've downloaded all 50 development library sets i find out that now i can't build my own projects because i've broken some system header somewhere.
Now that being said, most things compile fine right-out-of-the-tarball. Things that use grapics (opengl, x, widget sets) or sound, as well as things that use somebody's wacky portability layer or whatever tend to be _really_ touchy, and the documentation on what's required to build them is iffy at best.
That being said, there are some things i wold have expected to be a royal pain that aren't, like MAME, i build that from tarballs with no problems. On the other hand i tried to build a copy of gtk+ and it was like pulling teeth.
---
Play Six Pack Man. I
The way I see it, make the source and a binary available and let the developer decide what they want. Screenshots (if the project is far enough that they can be made avail) are always a good thing to have up on the project site. Though I know I miss a good app sometime, as a user, I somtimes make a call on what app I want to use based on how it looks.
A comprimize of having both up wouldn't hurt a thing. In all actuallity, a developer may not have all the binaries and libs required for the project at the time he looks at it, he may base his decision to help on if he can use the app, find a bug, then look in the souce to see if it's something he can fix.
Just my thoughts as a user.
Trying to be different, just like everyone else.
Screenshots can provide a quick measure of a project's interface and status. For example, I was looking for a file manager today, something like Midnight Commander, but improved. The first thing I did was check screenshots, and immediately I discovered many of the programs were obviously not what I wanted. Others had screenshots that were close, so I checked them out. After reading a bit, I tried getting a few to work.
Precompiled binaries come in handy here, as a lot of "under development" software doesn't compile readily under systems where, for example, header files are in a different location. Also, for large projects like Mozilla or XFree86, if it doesn't have binaries, life is a pain. Just untarring Mozilla takes many minutes, let alone trying to compile it...
Once you get something running, or at least can take a look at it from a screen shot, you can form your opinion as to whether or not to help the project. Unless you are a real die-hard coder, if it doesn't appear that the project has promise (based on it actually running, looking OK, etc.), chances are you're not going to help.
Long story short, screenshots and binaries make it a lot easier to find the software you want, and thus be interested in helping out the project.
Dipshit, I'm right here.. I ment screenshots. Think!
How we know is more important than what we know.
doesn't strawman also include just changing the topic to any old thing to divert attention away from the real argument. For example, if I'm loosing an argument and I say "well, what about those free trips you took to bali on the company money?" which you obviously have to defend or you will loose credibility. And what's the right term for "attacking the person instead of the issue"?
How we know is more important than what we know.
I can point to a few projects that use obscure languages and yet expect you to download and install the compilers and runtime libraries. In many cases - no native languages - you have no choice, like python for example.
How we know is more important than what we know.
This is very true. Programmers are also known as "lazy bastards." We don't like to spend much time dealing with compilation. However, programmers will get really pissed off if the source isn't there.
The only programs that I submit patches to are the programs I use everyday. So I'd say that software quality is number one importance; availability of binaries will get people starting to use it. Availability/readability of source code will eventually build the support base.
binaries create more enthusiasm for a project since not every linux user is a code-throwing god(TM). Remember, we want linux as a desktop for the masses, right?
I would have to agree with you. I don't always have the time to compile the stuff myself. To top it off, I am still new to Linux, so having to compile everything all the time might become information overload. Once I know Linuxx better, then maybe I will compile everything all the time, but I doubt it. It takes time--especially the first time you get the code.
I prefer screen shots. I like to know if there is a GUI or not, and if there is, if the design of the GUI is intuitive or just plan off the wall.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
I use Emacs for nearly everything I can. At home, I compile the latest myself, sometimes patched with something I'm working on at that moment. Of course, at home I have a real OS, Linux. At work, I use it under Windows. The system didn't come with a compiler and I don't want to sort out building it with Cygwin, not because I don't like Cygwin, but because I'm not working on porting it. The pre-compiled binaries allow me to use it in multiple places and only build on the machine where I'm actually working on something.
The net will not be what we demand, but what we make it. Build it well.
It's also a proof that you got the thing to compile so it's at least releasable as alpha code. I won't name the author or package of the really cool widget that would have been extremely useful for teaching the people I work with useful skills and giving them a testbed for trying out things, but once I got version 0.4 to compile (with a bit of help from the author on what packages he used), I couldn't get it to operate past the first step, and from reading the source code I'm not convinced there's any way the author could have done so either. So I suspect that either there's an old distribution around and I need to find the newer one (unlikely - it's in Freshmeat) or that the author posted the thing a year ago and hasn't done anything with it since then. (sigh... that's not what Abandonware is supposed to mean
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm writing my own linux game which will eventually (one can hope) be released sometime next year. I not only plan to show screenshots, but I also plan to release binaries. And yes, they will be x86 only.
It's not because I have anything against people who aren't on an x86, it's because I don't have any of the other platforms required :)
I'd like to make this clear when I release the game. Would something along the lines of "I'm providing x86 binaries only because that's all I have. If you'd like a PPC (or alpha, or sparc) package, and you have such a machine, contact me and I'll make you the official package maintainer" work?
I guess I'm saying that there's no reason for large companies who can afford to buy this stuff not to release a PPC binary; however I personally can't release one because I don't have the cash :)
-Denor
> they are talking about works-in-progress
I fail to see the difference. Linux is a work in progress. There are test kernels being "released" all the time. New features are added. More compatibility is added (e.g. Pentium IV). Etc.
> that is the way it used to be and it was a pain in the ass
I know. Now, how many of your garden-variety users are going to make a journey to hell and back (assuming they're even able to) to try out an operating system that they probably won't like anyway? If Linux is to gain any kind of marketshare in the desktop world outside of a rounding error, your average user is going to have to be able to use it. GUIs are a step in the right direction, but if Yooser can't compile GNOME or KDE, and he doesn't have binaries, his reaction is probably going to be one of two:
"This sucks!"
or
10 Enter chat room/message board
20 Whine
Goto 10
Source and Binaries reference different (overlapping) markets. Source is for the very adventuresome programmer, or the paranoid user. Object is for people who are more interested in seeing if it works. Otherwise said: some people like to break things -- some like to fix them. Even pre-alpha has a use for both groups.
In some cases, even non-technical users can notice things that are much easier to fix before a product leaves alpha.
In my own case, I will often download the binary out of laziness, and then, If I find a bug, I may either
1.) Report it to the appropriate authorities
2.) download a current ({non-.}recent) source
But, as far as I'm concerned, there's no need to download the source until I find a problem/future feature that I think that I can meaningfully fix/contribute to in that way. Until then, I'll submit bug reports -- whether I have the source or not.
`ø,,ø`ø,,ø!
Free Software: Like love, it grows best when given away.
The whole tenor of this discussion serves to amplify the notion that /. open source persons are pasty-faced guys who live in darkened rooms with a glowing screen, can't get a date, don't get out enough, and have little or no experience of the real world in which ordinary people live.
Most computer users are not programmers. They don't know programming. They don't know "build". They buy a magic CD from Microsoft or whoever, stuff it in the drive, and it works. Mostly.
If you want open source software to gain popularity among the masses, you'd better ship working binaries. With Installshield or whatever.
While you play about in your own backyard with a pile of incomprehensible source code and even less meaningful make files (quiet at the back, hackers! -- we're talking about ordinary folks here) you will not see mass take up of open source projects -- except among programmers who can't get a date and who can, therefore, while away their empty evenings finding out how to build someone else's half baked code.
I think any package that wants to be of production quality should do both. There are some people that just want the binary. And they should be catered to. There are admins out there who are just okay. That's the fact of life for any IT job. If you have an elitist view about who should be a box admin then you don't have any right to complain about more companies not using linux. You can't have it both ways. It's not like making a binary is a big task in the grand scheme of the development cycle.
However, that being said, source is also a good thing. For one, some applications may work better if they are complied certain ways. When it comes to squeezing every ounce of speed out of an app having the ability to compile for a certain CPU, or using static libs is generally a good thing.
Ahh, come on, goatse.cx isn't so ba-ba-ba-ba-bad. ;-)
It can get under your skin but then on a certain level it can be funny too (I've seen some really good puns involving it, like stories about fat download pipes, shitty interfaces, etc.).
--
News for Geeks in Austin, TX
"Precompiled binaries"? As if there were some other kind of binary?
Easy. Basic bytecode. Early versions of Basic stored programs in RAM as bytecode to save space. For example, print was stored as a ? character on GW-Basic. Some systems even allowed the user to enter the bytecodes directly as a keystroke saver, leading to the common shortcut ? for print.
Another kind of nonprecompiled binary is heavily obfuscated C code used in portable yet proprietary "Unix programs." There are several automatic obfuscators for C code, to remove comments, shorten variable names, and turn keywords into line noise.
Yet another is the system used by many Alpha compilers. The Alpha architecture is notoriously hard to generate efficient jumps for; many Alpha compilers store RTL (an intermediate format used internally by compilers) in object files so that they can do additional code optimizations at link time, when jumps are easier to handle.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
How did you build it? Apparently your compiler was binary too.
not a flame, a fact. Too bad too. Some people like myself like downloading programs and trying them without needing to track down 150 libraries and spend a day and a half trying to compile something.
oh that's right, if you aren't a complete geek, you don't have any business using this OS.
very sad people still think like this.
________
Source code is great, but so are binaries. Not everyone can understand or even compile code. Releasing as source-only won't really encourage more pairs of eyes to look at your code. It's likely to do just the opposite, IMHO. I'm not sure it's a good idea forcing things on people who got interested in open source because they wanted to get AWAY from that kind of abuse.
People who would go through the code for themselves probably would have done so anyway even if there were binaries available. Those who can't help in that capacity could STILL help if they had binaries to run, test and provide feedback.
I'd also classify screenshots as a good thing, as they give potential users some idea of what they're getting into. Asthetics aren't everything, but they're not completely without merit, either.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
works as well.
Releases for Windows:
./configure then make install
./configure and make install.
Executable install program, which decompresses and installs the program, and sets up the registry entries.
Releases for Linux:
A project.tar.gz file, which you tar zcvf into your home directory, then
Binary releases are pretty useless, since not everyone runs the same CPU and libaries. So you have to release stacks of binary releases. Just release a well set up source distribution that compiles on all (supported) platforms, with prominent information in an INSTALL file that points out what platforms it will and won't compile on. Where's the problem? Linux gets the arguments from the RPM crowd, and the apt-get crowd, but as far as I'm concerned you can't beat
As I said before, it's free speech to make your point, even make it a few times repeatedly. But when your point is, in my opinion, dumb, and you repeat it constantly, one begins to wonder if we're arguing free speech or just giving stupid people ammunition to piss others off.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
It may have something to do with being raised on Windows machines (or, even before that, TI/99-4A), but I've never had an interest in seeing the code of "professional" applications. Writing code for my own little apps is a different matter (also, whenever I produce something open source, I compile it for a few major distributions as binaries).
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Open source moves inexorably towards World Domination(tm). Of course, to achieve world domination will require dominating the world. The population of the world is somewhat larger than the number of programmers/hackers who live in it. In order to achieve world domination, open source must dominate the entire population of the world. This, by definition, must include both my mother and my mother-in-law. What do my mother and mother-in-law want? They want simple. Simplcity is elegent. Current open source is not simple: download, extract, configure, compile, debug, curse, bang head into keyboard, get new version of some obscure library, repeat. It seems that to achieve its destiny, open source must embrace those who are not programmers, maybe even AOL users .... maybe.
I am not a coder, but I am a user who can at least compile programs on my own. I have seen both sides of the fence, and there is a place for both.
Remember, the original question included a mention of being able to demonstrate the program. This says Binary to me, whereas getting people to test the program needs to include the compilation of it.
My short answer is therefore this: keep producing tarballs of source, but if you have a demo or similar, make an RPM to show how wonderful the program is!
There endeth today's sermon.
--Scientists today discovered signs of intelligent life on planet Earth.
They believe the species died out last year.
--
Scientists today discovered signs of intelligent life on planet Earth.
--I don't believe in .sig files.
Of course there's no hard and fast rule, after all the Linux kernel still only has source releases.
Well, one normally checks to see if the user is mature enough to see the binaries!
sulli
RTFJ.
Now, if you follow good programming practice one can avoid the common mistakes (usually endian errors and assumptions about the number of bits associated with certain types) but most people don't follow good programming practice. So releasing binary packages for multiple platforms is a good indication that the programmers are on the ball.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Now, if you follow good programming practice one can avoid the common mistakes (usually endian errors and assumptions about the number of bits associated with certain types) but most people don't follow good programming practice. So releasing binary packages for multiple platforms is a good indication that the programmers are on the ball.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
I'm far from being a hardcore programmer type (I'm really not that good at it...) but if you use GNU tools like make and autoconfigure, it shouldn't be all that difficult for even a casual user to figure out how to compile something. (./configure --prefix=/usr/local/stow/packagename-version && make && make install && stow /usr/local/stow/packagename-version )
(Sidenote, stow is your friend! GNU Stow
The advantage to this is that the end user has do more than untar the biniaries. This is good because some packages may contain newer versions of libiaries than the user has installed. Usually, the result won't be more than something wanting to be updated or recompiled, but you can break your system fairly easily.
Also with source you have a bit more flexiblity in what libiaries the user has installed. (You need version 1.4.5 or above rather than the version this binary was compiled agnist) You'll probally get less flame style e-mail whining about "Why doesn't this work on my l33t system?"
With software that isn't release quality, source only distribution is acceptable, and IMHO, the best option. Keep the riff raff away until it's closer to release quality.
Screenshots, well, you always have to have screen shots. I often just look at screen shots and say "not quite ready, probally not worth my time, yet. But gee, it sure looks cool..."
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
Bug reports and feature suggestions are immensely valuable. In fact, arguably, much of the value and enhancements to MS Office and similar products are the result of such feedback. And a good way of getting such feedback is by releasing binaries.
So, if you are able to provide lots of platform support with your binaries (like Netscape, Seti@Home, etc...) go for it. Otherwise, go over your makefiles with a fine-toothed comb.
-Alec
I third. Hey, let's put this on the next poll.
Of course, once you invest a large amount of time and effort into databases and scripts that rely on the quirks of some tool (either commercial or open source), you are not keen on tossing the whole lot out for new and better tools. Especially if the new and better tools do not fit into the hole the old one did.
Many of us just like to unwrap the present and play with it, not spend the half-afternoon making the toy and then seeing if it fits our needs. Even if the compiled binary were 85% effective, it will give us an idea of what it does. {sarcasm}The largest software manufacturer in the world makes 85% effective software, and you feed in the other 85%!{/sarcasm}
OS/2 - because choice is a terrible thing to waste.
If you install GNU Emacs on a classic Mac (Pre OS 10) you can use (esc)-x-shell to drop down to a shell. Then you have the very primative ability to crawl around in the Macintosh filesystem with a few commands (ls, cd, a few others). I suspect the command line could be extended with some lisp code.
Yep, that's one way to get to the command line (and be able to textually move stuff around) on a Macintosh.
Hay thar.
There seems to be an unspoken assumption in this thread that open source programs are intended to run only on 386-compatible Linux boxes, so that one set of binaries will suffice for all users. Releasing binaries only for that standard vanilla platform is a nice way of reminding users of other systems that they are second class, and also this kind of development is a nice way to make sure that your software is less portable than it otherwise should be.
For this reason I think it's better in the early days of a project to release source only. Binaries can wait until the software's in shape for use by non-programmers.
The benefits of this, if I think the idea behind the project is cool and it's been in an active development state and I download the source tarball and try to compile it and it fails I will probably desert the project. However if I look at something that actually runs to see if the time they've spent has been good and that it looks pretty solid and has a good start, then I'll wrestle with getting their CVS/alpha/pre package to compile and build on my machine.
Whoever thinks binaries are a bad thing, with no good merits I feel sorry for them. However, any application that I use on a regular basis will be compiled from source and optimized for my platform if possible.
Dacels Jewelers can't be trusted.
Developers aren't the only needed participants in Open Source development. Taking the attitude that only developers can contribute is very bad. The guy that certainly is not a engineer, but a mere coder (can hammer and saw but cannot build a house).
A non-developer that has access to a binary can:
a) Write documentation, tutorials, etc.
b) Excercise the application in ways that a user would, thus finding bugs that a developer would not.
c) Ensure that the program does what it is supposed to. If there are reqs or specs, then they can be tested. If not at least it can be tested against the "web page".
d) Get excited about the project and tell all of his developer friends.
A Government Is a Body of People, Usually Notably Ungoverned
There's plenty of apps out there that are in a constant state of development, and yet are usable because of milestone builds. Two good examples are Mozilla and Evolution - both (IMHO) excellent apps which, thanks to having easily installable binaries (both are apt-able) I can easily use in a production environment at work.
:) ) I used to compile moz milestones myself, so I could ditch the mail/news component and other cruft which i didn't use. Milestone binaries are A Good Thing (TM), but they need to come with source to be really worthwhile.
However, it's important to note that source is avaliable for both. Before i had a full-time job (and less than 512Mb of RAM
I've found that releasing binaries are essential
:) don't want the hassle of compiling the
to making an open source project successful.
That said, I usually don't release binaries for
alpha releases or early betas that are likely to
contain bugs - better to let the more experienced
hackers (in the true sense of the word) run into
any problems and report (or even better - fix!)
them than spend days with a newbie only to find
that they haven't found a problem but are using
the thing wrong.
Once you know the code is stable enough for
mere mortals to use, get the binaries out! A lot
of inexperienced users (and experienced ones,
too!
software themselves if they don't have to.
I print, therefore I am.
This assumes you are writing code with gcc. If you are using one of the other myriad of compiled languages available, everything from Lisp to OCaml to Pascal to Eiffel, then you most certainly want to distribute binaries. Not everyone has the latest versions of those compilers sitting around. There are sound software engineering reasons to not use C and C++ for everything.
But the big problem I see with asking people to compile programs - and this goes for binaries, too, since they are typically GPL'ed and you need to have the source code available, is the dependencies.
In other words, who here has compiled enlightenment with all the options? How many packages from other people do you need? How many image libraries and crap do you need? It gets ridiculous, because often those libraries have depencies of their own. I like keeping things simple, myself, so I just don't do it - enlightenment is a good example of something that I might want to try - but not enough to spend hours online downloading depencies and then wading through it all to make sure everything gets compiled in the right order. So I tried what came off my linux distribution and thought it was kind of bloated for my liking - saved myself a LOT of time.
----------
Stupid sexy Flanders.
I like the idea of releasing binaries AND source. Some programs, such as gnome or X, i just dont have the patience to compile from scratch, so RPM's are convenient. Other things, such as GAIM, i update from CVS daily. As for screenshots, i like to use those when first downloading a program to see if the program is jsut a gui or is actually filled with a few features. Sometimes they are misleading, but they are good for hooking new users. It's all personal preference.
I am !amused.
Distribution of binaries is of the utmost importance for platforms like Windows, where a compiler does not come with the operating system, and the compilers that are readily available are often non-free.
So what if MinGW or Cygwin doesn't come with the system? They're both easy to download and install, and they're both GPL'd free software (based on GCC and other GNU stuff). Or, you can use the (non-free but free beer) LCC compiler. However, Mac OS 9 systems (that can't run OS X because don't have a G3 mobo and 128 MB of RAM), on the other hand, don't even have a command line; good luck getting GNU anything to work.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
Problem solved.
Let us not lose sight of the fact that we are talking about the creation of Software, who's ultimate goal is to be usefull. Some people do not wish to program, but are willing to supply a list of bugs that have been found. This is an important part of the development process, even in Alpha stages. It is said that a bug caught in the earlier stages of development and fixed in an hour, may take weeks to fix if found at a later stage. So yes, allow the binaries to be downloaded. You may lose a programmer or two, but, in the long run you are allowing a greater range of people to contribute through commentary and bug reports. Falkenberg
The truth is that it is in the packaging. Any time that something becomes difficult to install, many people will drop it. For example, I was just trying to get Bochs up and running last night. When I tried to compile the code, the compile would fail every time. I went in and found that some of the header files had a definition of NULL that the compiler didn't like. So I changed it and tried again. Now it was something else. So I found the binary for my system and tried that. Of course, libstdc++ just said "symbol __ti9exception not found". Finally, I just downloaded a BSD ports package which installed and ran without issue, even though it was source.
The reason why binaries are more popular is that they are generally easier to package. The dependancies of source is such that you must have the right compiler, the right linker, the right header files, (sometimes) the right platform, etc. The dependencies with binaries are such that you must have the right platform, and the right libraries. The libraries can often be included or automatically installed via a packaging system. This makes binaries far easier to get running.
So what's the moral of the story? Package your binaries to meet the needs of the target audience, and package your source to meet the needs of its audience. Between these two, your customers (paying or not) will be far more pleased.
Javascript + Nintendo DSi = DSiCade
I also download both the binaries and the source (nice to have a cable modem) depending on the program. As has been mentioned, I'm not interested in compiling a spreadsheet or word processor. Trying to force me to do something a developer should be doing isn't going to make me want to help.
Everybody has their area of interest, and in those areas I'll look at the source, and maybe change and compile it, but not for the other things. It's ridiculous to feel everyone should have to compile a program. Don't we want to encourage use of Open Source across demographics of users?
In any event, not giving binaries will open the doors for new websites, maybe ad sponsored, that let you download the binaries anyway.
----------
Stupid sexy Flanders.
I believe that the lack of binaries being released for linux is one of the major drawbacks that is keeping it from becoming a major OS competitor. Many of my tech-friendly friends have installed linux, but lacked the programming skills to install a lot of the software they wanted. The difficulty of compiling software has actually made some of my friends reject linux as an operating system. I do believe that source code is important, but for linux to become a viable operating system, binaries will have to be released more often, or at least an easier way to install software.
Is anybody else on Slashdot tired of these childish goatsex links? It really is a distraction, even after I set my threads to +1 and above (occasionally I want to dip down to see what AC's say, and most of what I read are these links).
Two suggestions: AC's who post this, get a new hobby. Even the juvenile posts about grits were better than this (no image to fill up my workscreen).
Second, Rob, Hemos, whoever's in charge of these decisions: ban the dumb link. It's one thing if it's "freedom of expression". It's another thing to see the same damn picture over and over and over again. If you cry "first amendment right", let me just say we heard you the first time, poster. Now grow up.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
If I can see a screenshot, I can get an immediate idea of how the interface of the program works. As a UI designer/developer, I'm SUPERPICKY about interfaces on the apps I use.
There are many FTP clients, for instance, and most of them will do everything most people expect them to be able to do. The difference for most of them is in the _interface_.
Downloading a screenshot lets you know right away whether this this looks like the kind of interface you'll be happy with, without the trouble of downloading a full binary and installing it, much less the time and trouble of downloading source to an app, compiling it, installing it, etc. If all you want is an idea of the interface concepts being used, a screenshot is the ONLY sane thing to use.
Mind you, that's about ALL it'll tell you - but the interface is all-important. It doesn't matter what an app is capable of if you can't figure out how to use use it. What kind of life is it you lead if you're willing to put up with annoyingly-designed software all the time?
It could also be used by savvy app developers to find out what people think of their app interface. If you have the binary or source available on your site, and a screenshot or two, take note of how many people check out the screenshot versus how many download the app. Take a look at the ratio and get a clue about your interface. There's a REASON KDE & Gnome exist.
People who want source will click for source. Certainly I've debugged many a Debian program starting only with a binary, and then downloading the Debian source package.
Thanks
Bruce
Bruce Perens.
OK. Say the Linux distributions didn't want to release procompiled binaries. Say they wanted to make their users truly understand how the various distros work. How many of you would still have tried Linux if you had to compile all the binaries yourselves?
Eric Raymond in his seminal work, The Cathedral and the Bazaar, stated that one of the ways to create a successful Open Source project is to release something that developers can use and find useful. As a developer it is easy for me to run a program and decide if I think it has potential or not, on the other hand it's a pain for me to look at 10 - 100 source files trying to figure it if the design is good and why I can't compile it.
Another good thing about releasing binaries is that it gives the developers more incentive to fix bugs and create milestones than if they just released source and makefiles at random because it means they have to make the software run as smoothly as possible and tackle usability/configuration problems early.
In my opinion screenshots are not as useful but still serve a purpose such as enticing people who are just browsing through projects at Sourceforge to take a closer look at your project.
Grabel's Law
Today's world is so much nicer... "./configure", "make", "make install" (well, I'm a bit wary of that last part, as it usually needs root). When this very nice process doesn't work, usually the configure script tells you when you need to do. Pretty cool.
Still, there are source-only distributions that fail to build. Now I can understand this if it's from an up-to-the-minute CVS, but from a tarball on a web page or ftp server, that's not so cool. As a programmer, the software needs to be something pretty special for me to go dig in and fix the build process. It's just not fun work (particularily for a large project), and unless you've got quite a bit of experience, it can be nearly impossible.
So if you're an open/free source author and you don't offer binaries, make sure the code builds on the systems you're hoping your users have.
PJRC: Electronic Projects, 8051 Microcontroller Tools
Several reasons:
I think it depends a lot on the project. My only open-source project is an applet that shows the planets in the night sky. I've gotten lots of help from strangers with translating it into various languages, and that's actually the full extent of other people's involvement since I open-sourced it. I don't think any of those people would have known or cared about the project if it hadn't already been an applet that was sitting there on my web page and was actually useful for something.
Find free books.