Why Are Binaries And Screenshots Good Things? 254
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?
Source Code ---------- (Score:1)
Source code is great to have when you are :
1. know how to compile!
2. know how to compile
3. know how to compile!
Basically, we compile source code not to look at the code but to optimize it to our individual system as much as possible wither it being to compile it or changing some lines of code.
Look it another way I want a program like star office to say now do I really want to compile it? Or have knowledge to do so like my uncle,no! Linux has came a long way but this issue is really scaring me to the future is going. People have to understand that not all Administrators or Coders are using linux or getting into linux anymore . The average folk are Binary is important in this case the average user want to download it and install it not think of compiling it.
Binary and source code should be out on ever release od the application atleast there should be both present at every major version change. Like 1.0.8 to 1.0.9 should but it is not needed, but like 1.0.8 to 1.1.0 this should have both binary and source present!
Ban the link? (Score:1)
Are you suggesting that all links to *.jpg and *.gif files be banned by slashdot?
I say a bit arrogant. (Score:1)
I say binaries and stand alone binaries specificly, are atleast as important as the source code. You need a method for non-programmers to use your software... after all it was written to be used, not read.
Re:binaries are the way to go (Score:1)
Re:binaries are the way to go (Score:1)
supporting morons is so fun, i can't see why developers wouldn't want to do LOTS of it.
Re:Precompiled binaries (Score:1)
Well, I've been using Linux ever since the good old days when one had to attack a freshly compiled kernel with a binary editor to tell it how to get at its root file system (2 bytes somewhere in the vicinity of 508 IIRC) and other "heroic" things like that. It goes without saying that I've moved things over to another box since then (although the old one still works just fine under DOS for my father, even after 9 years).
--
Re:Precompiled binaries (Score:1)
So yes, binaries can have use even for non-average users who theoretically are perfectly capable and willing to work with the source.
--
Binaries and Screenshots (Score:1)
Generally I don't even bother to pull binaries, because they're often in RPM format and I don't use Red Hat -- the RPMs are often not quite right for my SuSE system, and my Slack and Debian boxen don't do RPM. (Okay, Slack 7.1 does include RPM, but it's not really integrated nor do I want it to be...)
If something is in alpha or early beta, leave it in source form. Users who can't compile their own software are probably shouldn't be mucking about with alpha software. Not to sound elitist, but alpha apps aren't supposed to be 100% usable and users who can't compile code aren't going to be able to do much to help out...or reap much benefit from the software until it's further along.
Screenshots, on the other hand, should be totally mandatory...and decent install instructions would be nice too. Sticking source code on SourceForge saying it's the greatest thing since sliced bread without demonstrating the software or explaining how to install it is pretty much useless. One of the complaints I have with SourceForge is since it has a default Web presence most projects don't put much time into their presentation of the software -- which doesn't entice users into actually trying it. Just one or two measly screenshots is all we ask...
Re:Precompiled binaries (Score:1)
My first linux distro (based on the 1.2.10 kernel), was compiled entirely from source using a cross compiler on a Solaris SPARC5 system. There are several ways to build a distribution completely from scratch. Another option would be to use a DOS/Windows to Linux cross compiler.
Re:binaries are the way to go (Score:1)
I suppose it depends on who "we" are. Personally, I see no reason for developers to feel obligated to support clueless users. It's not the developers, I'm sure, who want clueless users. Why put up with constant whining, bitching, and moaning when in all likelihood you're not making any money on the venture? I've talked to people who seem to feel that, once you get down to it, "this Linux thing" they've read so much about should be better than what they currently have--an OS and other tools put together mainly by Microsoft, largest company in the world and holder of a significant concentration of the world's wealth.
Why should free-software developers live up to the up-on-the-pedestal image that mainstream press expects it to live up to? If mainstream press wants Linux to be better than the Windows and MacOS world from a clueless-newbie POV, perhaps mainstream media should fund/develop on their own.
Re:Enough with goatsex. (Score:1)
Probably a weekly/monthly release would be good (Score:1)
This way people who are interested in the project, but are not autoconf/make/gcc whizes don't have to worry about problems, and can take a look at how things are going.
The question that just came to mind is - what generates more useless questions:
- no precompiled binaries and lots of "I can't get this to compile on my system" questions
- precompiled binaries and lots of "I can't get this to run on my system" questions
Re:Precompiled binaries (Score:1)
Besides, that is the way it used to be and it was a pain in the ass.
Re:Precompiled binaries (Score:1)
"Precompiled binaries"? As if there were some other kind of binary?
-- Brian
Re:binaries are the way to go (Score:1)
Re:Why is it a big deal? (Score:1)
However, one strong argument in favor of binaries is KDE. I downloaded and compiled that monster -- it took something like SIX HOURS and I have a fast machine! I'm assuming that it is C++ that is causing the problem. KDE's source packages are pretty big, but I don't think any of them is even as big as the Linux kernel, which I can compile in around ten minutes.
I don't know if it's a problem with gcc or just in general with C++. From my experience so far, that language might be the best argument yet for distributed precompiled binaries.
As a rule of thumb, if it's going to take longer than an hour to build, I'd strongly suggest distributing binaries with or in addition to a source package. Anything over an hour turns 'an experiment' into 'a project'.
As an aside, I sure hope the KDE developers are getting a benefit worth that kind of compile-time hit. God that installation sucked. :-(
Compiling programs (Score:2)
But for alpha software, sure, make them compile it. If it doesn't compile it shouldn't have even been released to alpha...
-E
Goatsex with class. (Score:2)
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.
Re:You missed some parts (Score:2)
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.)
Re:compiling with -g just wastes disk (Score:2)
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
Why not source that is as easy as a binary? (Score:2)
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.
Re:Lack of binaries hurt. (Score:2)
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.
--
Re:Lack of binaries hurt. (Score:2)
--
Speaking as a skilled developer without the time (Score:2)
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
Re:Lack of binaries hurt. (Score:2)
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
different issues for huge programs (Score:2)
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.
Binaries for the 'Leet (Score:2)
Re:binaries are the way to go (Score:2)
simple, use source packages (Score:2)
--
The grabber's point of view (Score:2)
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 OK but... (Score:2)
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.
Binaries: why? (Score:2)
./configure
make install
Which is about all it takes to install 95% of the stuff out there from source...
Re:Why is it a big deal? (Score:2)
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.
Re:Why is it a big deal? (Score:2)
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.
Re:Why is it a big deal? (Score:2)
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.
Jack'o'lanterns (Score:2)
screenshots.. a picture... (Score:2)
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!
binaries, tarballs, and suffering (Score:2)
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.
--
Re:Precompiled binaries (Score:2)
Builds are often non-trivial (Score:2)
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.
make both available (Score:2)
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.
Both help find what you are looking for (Score:2)
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.
Re:Screenshots? (Score:2)
Re:Straw... (Score:2)
Re:This is a C-centric question (Score:2)
Re:As a developer.... (Score:2)
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 are the way to go (Score:2)
Re:Mixed ideas... (Score:2)
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.
Why I like binaries (Score:2)
Alpha Code often doesn't compile reliably; demos (Score:2)
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
But I don't have a PPC.... (Score:2)
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 :)
Re:Precompiled binaries (Score:2)
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
You can't fix what don't show cracks (Score:2)
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.
`ø,,ø`ø,,ø!
Most Computer Users Are Not Programmers. (Score:2)
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.
You should do both (Score:2)
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.
erhilechda! Re:Enough with goatsex. (Score:2)
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.).
--
Non-precompiled binaries (Score:2)
"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 [pineight.com].
Re:Precompiled binaries (Score:2)
if you don't have a CS degree, use windows. (Score:2)
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.
________
Not everyone is a programmer. (Score:2)
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.
Re:Enough with goatsex. (Score:2)
works as well.
My view (Score:2)
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
Re:Enough with goatsex. (Score:2)
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.
Use vs. Development (Score:2)
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).
Gee Brain, what do you want to do tonight? (Score:2)
Re:Coders vs Users (Score:2)
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.
Re:Precompiled binaries (Score:2)
Of course there's no hard and fast rule, after all the Linux kernel still only has source releases.
Mature enough for binaries? (Score:2)
Re:Binaries for which system? (Score:2)
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.
Re:Binaries for which system? (Score:2)
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.
Source vs. Biniaries (Score:2)
(Sidenote, stow is your friend! GNU Stow [freshmeat.net]
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..."
you want bug reports and feature suggestions (Score:2)
Binaries are x86-biased anyway (Score:2)
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
Re: Enough with goatsex. (Score:2)
I third. Hey, let's put this on the next poll.
Learning from code (Score:2)
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}
Re:Free Windows compilers (Score:2)
Yep, that's one way to get to the command line (and be able to textually move stuff around) on a Macintosh.
Binaries for which system? (Score:3)
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.
Why is it a big deal? (Score:3)
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.
Re:binaries are the way to go (Score:3)
I desperately would like to see Linux and/or BSD become more user friendly and more used, so that I can ditch Windows solutions completely and use one or both exclusively.
Developers aren't the only needed participants (Score:3)
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.
Milestones are A Good Thing (Score:3)
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
Alpha Binaries - No, Beta and Releases, Yes (Score:3)
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.
This is a C-centric question (Score:3)
Re:Lack of binaries hurt. (Score:3)
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.
----------
Mixed ideas... (Score:3)
Free Windows compilers (Score:3)
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 [mingw.org] or Cygwin [redhat.com] 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 [virginia.edu] 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 [pineight.com].
Re:Enough with goatsex. (Score:3)
Problem solved.
Re:Why is it a big deal? (Score:3)
Binaries are susceptible to all sorts of little inconsistencies between installations that source can pave over. The result is a flood of "I get this this error on Storm Linux with XFree86 and GTK whatever." mails. Also, releasing source-only creates a small barrier to entry that restricts distribution to people who understand what "pre-alpha" means.
Screenshots, on the other hand, seem like they're always a good thing.
Binaries a MUST!!! (Score:3)
Packaging (Score:3)
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.
Re:binaries are the way to go (Score:4)
We do? I for one just want the best OS for me, I don't care who else uses it... If to attain that we need to get the masses using it, so be it. But it's not a goal in itself.
Both (Score:4)
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.
----------
Lack of binaries hurt. (Score:4)
Enough with goatsex. (Score:4)
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.
screenshots are absolutely necessary! (Score:5)
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.
Provide early binaries, but maybe not Alpha (Score:5)
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
Precompiled binaries (Score:5)
Releasing binaries is a good idea for many reasons (Score:5)
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
if (dist==SOURCE_ONLY) comile_without_hitch(); (Score:5)
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.
Early, not late (Score:5)
Several reasons:
I think it depends a lot on the project. My only open-source project [lightandmatter.com] 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.