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?
I see both ends of it good and bad. Some users are getting into linux like they would windows and don't know a thing to code and compile some people mentioned that compiling a source code is easy .. It is but you have to look of in terms of most people. Most people is like a Uncle of mine that knows to get it on and get into M$ Office. Others know everything to linux other don't and we have to look at the whole picture.
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!
How do you expect them to ban the link when the image can simply be mirrored at several different URLs as is done now?
Are you suggesting that all links to *.jpg and *.gif files be banned by slashdot?
I find it a bit arrogant to say that users are downloading your software merely to look at the source, and not the functionality. I download programs to use them, not compile them or spend an hour working out dependencies.
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.
non-profit development makes good sense to me. non-profit supporting of idiots doesn't seem near as fun or as appealing. in the commercial world programmers don't support the users of user level applications. i don't know why anyone would expect opensource developers to waste their time on the annoyance. for profit? the users don't want to buy a support contract.
cry me a fucking river.
supporting morons is so fun, i can't see why developers wouldn't want to do LOTS of it.
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).
--
Linux user since early January 1992.
So yes, binaries can have use even for non-average users who theoretically are perfectly capable and willing to work with the source.
--
Linux user since early January 1992.
Posted by polar_bear:
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...
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.
"Remember, we want linux as a desktop for the masses, right? "
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.
Stating on Slashdot that I like cheese since 1997.
Not good enough.
Stating on Slashdot that I like cheese since 1997.
Depending on how fast the project is moving, a regular binary release would be good - either weekly/monthly/whatever. Or if some major feature has been added.
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
Completely different scenario - they are talking about works-in-progress, not something released.
Besides, that is the way it used to be and it was a pain in the ass.
"Precompiled binaries"? As if there were some other kind of binary?
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
And if they are a "code throwing god" they may not be one in the particular arena that the software is written. For instance I think of my self as a pretty good Perl coder and a strong web developer, and I could dabble in C, C++ but I wouldn't even want to look at Java source (I have seen enough of it already) or let alone tackle my own driver for the kernel (even though I recompile that anyways). For me it has less to do with compiling or building than the fact that I wouldn't help on an Open Source project unless I was interested in it and that I could contribute something more than inefficient buggy code.
Funny and I thought Perl == Paid employment recently located
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. :-(
No, this is NOT absurd. It's not only possible, it has HAPPENED.
Not too long ago, there was some common system package where the original distribution files were replaced with hacked binaries. The 'trusted' distribution site had been compromised. It was caught relatively quickly (about a week I think), but quite a number of bad copies went out.
re: KDE, were you doing KDE 1 or 2? I was on a 733Mhz P3, fast SCSI drives, 256MB of RAM, and it took about six hours for the full compile-and-install process of KDE2. Further, the set of directions I was reading also suggested that it would take a very long time. Because of this, I suspect that you were doing KDE1.
Binary distribution seems entirely appropriate in this circumstance.
I bet 95% of slashdot posters didn't even know that there's a per-process core-dump-size limit that they might want to clear from main() for a debugging executable. Also, I did a text search and nobody was even covering -g. The rest of the post was, I admit, mundane.
Thanks
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Just be prepared to wait a long, long time for that.
Not enough.
Users may not WANT to understand how the distros truly work and it would be suicidally bad to force them to compile their own binaries.
Just because someone might think users SHOULD learn how an OS is put together doesn't mean it is the right decision to make. You'd only keep out those who couldn't be bothered and stop a great many people from beginning to learn about computing outside of the Windows environment.
What's the term for this? When you pretend to have an issue worth debating when you really don't?
Fighting a straw opponent? It's straw something or other. Help me out here.
whoever said I for one minute complained or believed Linux to be viable for the desktop? You are jumping to conclusions..
Linux has its place. It does its job, and it does it well... If you are willing to take the time to use it you will enjoy it. If you want to just use your computer for whatever, Windows is there for you as well (yes, it serves its purpose too).
Just because I run Linux myself does NOT mean I believe it to be ready to take on MS's dominance i the desktop market.
Binaries are important, but not even close to the importance of screenshots. Without screenshots I don't bother downloading (unless I've seen it before, etc). Putting up screenshots must be one of the simplest ways to attract users. Even if the app is text-based I want to see an xterm screenshot (unless it's a non-issue, like a daemon app, etc).
As it is, I know most people run at least one commercial (Windows usually, sometimes Apple) OS on their personal networks to do things like watch DVD's, look at the (quite numerous) video files made with the Sorenson CODEC or other formats for alternative OS' lack viewers, visit sites that require specialized plug-ins, and, if nothing else, play games.
Of course, if all you need from a home system is email and a SQL server, then you don't have a thing to worry about.
and how pray tell do you know where in the code to look when it drops core without having debug symbols in the binary? Maybe in the trivial little applications you've written it's been obvious, but try that with (for example) Mozilla. Core faults from stripped binaries are a waste of time.
That is not true. If the expression is considered obscene by community standards, it is not protected.
Free Mac Mini. Yes, I'm
Sigh... Ill be freaking jumping joy, when linux has stablized, and you really can download 1 binary!
:(
Elf/A.out/which glibc, which kernel, SMP or not.. GCC 3 or GCC2.95.2 maybe EGCS..
Lets not even talk about X support. Having troubles getting my Voodoo5 working with 4.0.1 still! NO q3a for you!
-Brook
/me dreams of gcc 3.0 and 2.4 released....
11/17/2000 05:53PM 568,841 Kernel-Win4Lin1-Caldera2.2-01.i386.rpm
11/17/2000 05:53PM 613,332 Kernel-Win4Lin1-Caldera2.3-01.i386.rpm
11/17/2000 05:53PM 5,038,443 Kernel-Win4Lin1-Caldera2.4smp-02.i386.rpm
11/17/2000 05:53PM 4,282,892 Kernel-Win4Lin1-Mandrake6.1-7.i686.rpm
11/17/2000 05:53PM 664,751 Kernel-Win4Lin1-Mandrake7.0-15.i686.rpm
11/17/2000 05:53PM 5,182,061 Kernel-Win4Lin1-Mandrake7.1-9.i586.rpm
11/17/2000 05:53PM 669,703 Kernel-Win4Lin1-RedHat6.0-15.i386.rpm
11/17/2000 05:53PM 676,992 Kernel-Win4Lin1-RedHat6.1-20.i386.rpm
11/17/2000 05:53PM 662,812 Kernel-Win4Lin1-RedHat6.2-1.i386.rpm
11/17/2000 05:53PM 695,738 Kernel-Win4Lin1-RedHat6.2smp-2.i386.rpm
11/17/2000 05:53PM 747,324 Kernel-Win4Lin1-SuSE6.1-01.i386.rpm
11/17/2000 05:53PM 752,428 Kernel-Win4Lin1-SuSE6.2-01.i386.rpm
11/17/2000 05:53PM 784,591 Kernel-Win4Lin1-SuSE6.3-01.i386.rpm
11/17/2000 05:53PM 865,331 Kernel-Win4Lin1-SuSE6.4_2.2.14-02.i386.rpm
11/17/2000 05:53PM 901,433 Kernel-Win4Lin1-SuSE6.4smp_2.2.14-02.i386.rpm
11/17/2000 05:53PM 678,125 Kernel-Win4Lin2-RedHat6.2_2.2.16.3-4.i386.rpm
11/17/2000 05:53PM 710,005 Kernel-Win4Lin2-RedHat6.2smp_2.2.16.3-4.i386.rpm
11/17/2000 05:53PM 717,444 Kernel-Win4Lin2-RedHat7.0_2.2.16.22-1.i386.rpm
11/17/2000 05:53PM 748,662 Kernel-Win4Lin2-RedHat7.0smp_2.2.16.22-1.i386.rpm
If the software is far enough along that the application is usable, then it would be a good idea to have it available in binary format. I LOVE screen shots, as it helps me see what I'm about to download... especially nice with games.
It isn't that difficult to have a tar.gz file with the binaries, its not like you haven't compiled it yourself to test it. While it may be one of this little annoying things that have to be done, it helps the program more user friendly. I don't know how many times I've downloaded a basic Linux program that I couldn't get to compile due to missing pieces that if the author had just compiled it beforehand, it would have worked out of the box.
A slip of the foot you may soon recover, but a slip of the tongue you may never get over. -Benjamin Franklin
At least one of us.
Take into account that RPM makes managing installed software a snap. I prefer this over a pad and pencil next to each of my servers. Code is good to have available as well (SRPM) and I believe projects in alpha or even some beta should be distributed with emphasis on source code. This gives the blooming program a chance at more eyes and that means more bugs squashed.
PRIME - Indivisible by anything but ME!
While it's quite true that the first ammendment doesn't apply outside our borders, it should. It is a fundamental right. Any government that significantly (or even insignificantly) restricts it is wrong.
As for my attitude on pollution control, you don't know what it is. You only know the attitude our leaders present. They don't speak for me. Of course, I wouldn't expect you to understand that if you don't believe the first ammendment is a fundamental right.
Need a Python, C++, Unix, Linux develop
Work for IBM do ya? Heard they've implemented such policies for AIX developers.
-lx
As long as the project will run and won't destroy a users home directory (or even if it will, as long as it's clearly noted that may be the case in the README), then there really is no harm in releasing alpha binaries to users... They may not work. They may not be feature complete. But they may find a use for it, and let the author know. They might find a glaring hole, and do the same. They may be able to offer some advice/requests as to how the interface could or should work.
.tarred archive of the binary and libs needed to run it. It gets the project potentially into sights of a much larger crowd than if it were just made available to people that might actually build with the code....
The point being, if it does compile, there really isn't much harm in making available a
Just something to think about...
I AM, therefore I THINK!
It's not a question of what format is the best for a software release. This is a discussion about sekrit Programmer Code Language.
See, there's an unspoken language out there whose alphabet consists of the myriad combinations of source and/or binary releases for any given particular project. Providing one or the other, or both, is not (like many unsuspecting slashdotters think) simply a personal preference or a technical issue. Nay, it is truly a form of communication; ways for the Programmers to communicate certain points about the given project to each other while leaving the average end user uninformed, but otherwise none the worse for wear.
As I am versed in such a language, I shall provide - for your reading pleasure - some of the most common Programmer Sentiments translated into Common English. I may disappear after revealing this knowledge, so use it well:
Releasing Source-Only = "This is a GPL'd project that I'd like to keep to developers only. I'd much rather the average user not get his/her hands on it, 'cause I know it's buggy and I don't want emails from the clueless. Download and compile at your own risk, and if you actually get it working, then your system is configured similarly enough to mine for me to answer any questions you may have."
Releasing Binary-Only: "I am Microsoft. Give me your money."
Releasing both Binary and Source: "This is a GPL'd project that I am proud of, because I think it's useful and kool and l33t and stuff. I want everyone and their grandmother using this software, because it's so rad that it's amazing people have computed without it for so long. I have even taken the required 5 minutes or so to make this installation virtually painless to even the newest of users, and for any developers who may get blown away by seeing it run (i.e. all of them), I've included the source code for patching and viewing. I am a conciensous programmer who realizes that software is not released in a vacuum."
So now you know.
May the One shine in us all, even if we just want to run KDE - not compile it for 4 hours.
--WorLord
I'm strongly against binarys myself...
I personaly would like it if the avrage user did download the source and use that instead of a precompiled binary..
There are just to many advantages to compiling from source that a person gives up.
It's soul disadvantage is that it's a long compile and many "newbies" or "not expert users" don't know how to compile.
In the long run... if you don't care... you don't care.. and if you don't care and don't want to mess with a long compile (and maybe a long download as binarys tend to be smaller than source) then download the binary.
Newbies need a start ground.. binarys is that ground..
So.... binarys unless you have a really good reason... (like scripts where the code is never compiled or only compiled at [load/run]-time
I don't actually exist.
It's also a proof that you got the thing to compile so it's at least releasable as alpha code.
How bizarre! Are there really developers who view a successful compile as a milestone of somekind? In my mind, the software should have been compiling ages before it ever got the "alpha" label. Alpha software should be fully functional, just buggy. Beta software should be without any known (to the developer) bugs.
A Government Is a Body of People, Usually Notably Ungoverned
remember the response when Netscape released their PR1 version of their browser?
PR1 was advertised as "beta" software. Their mistake was calling alpha software as beta.
A Government Is a Body of People, Usually Notably Ungoverned
EXACTLY! Getting critical mass is one way of doing this, getting emulators/wine to work 100% is another way. What I'm trying to say is, the getting critical mass is not a goal in itself...
This is exactly what I meant. Getting critical mass is one way of doing this, getting emulators/wine to work 100% is another way. What I'm trying to say is, the getting critical mass is not a goal in itself...
Actually, you should have ancestors that tasted terrible!
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
Programmers who do not provide screen shots seem to make programs that are difficult to use, even if the programs have cool capabilities.
Sorting out the dependencies is the whole point of packaging, ie .deb, .rpm, et cetera. If sources were distributed in those formats with proper dependencies, all one would have to do is type apt-get mythingthatIwant and it will be magically updated.
Formats other than straight tar-ball with a 10-page README on how to get it to compile should be the norm. Topological sorting is something best left to computers, because people don't want to do mundane tasks.
-S
But that is a really huge "maybe." You have to ask yourself, can the worlds largest "wrong" population actually be expected not to use thier hardware as a cupholder? 8:o)
AOL. Because 26 megapeople can be wrong.
--
Help us build a better map!
Like a compiler (e.g. gcc)
;)
If you don't have a compiler, it is very difficult to download the c source of a compiler and compile it!
(Then again, maybe newbie computer users should be forced to learn this the hard way
I obviously can't speak for anyone else, but I know that on almost all occasions, when I download the source of a program I compile it, install it, and delete the source. Then, if I like the program or want to contribute to it, I redownload the source and take a look at it. (Sure it'd be more efficent to keep the source until I knew if I wanted to contribute, but I never think one step ahead) My point is, I don't look at the source right away. I only look at it once I decide I want to contribute to a project. With a precompiled binary, the process wouldn't change. I would see that the project is worth contributing to, and I'd download the source.
-- kapheine
What? You mean Slackware? That IS what I started with (-=
You Like Science?
You Like Science?
You Like bottomquark.
And now, a screenshot of the prefect ftp interface:
MarNuke
If the software is release quality, package binaries too, by all means. But keep source available.
Binaries are important to maintain interest in a project, particularly large, long compiles. In my case I usually install as much as possible from source (for better compiler optimization). I distribute my project in source form only, but I try to make it so that it will compile as easily as possible. My system is such that binaries compiled on it will not work correctly with any stock linux install. This is the downside to binaries under linux. There are so many different, somewhat incompatible versions of many libraries (i.e. glibc) that binary distribution is difficult to pull off for everyone. The code base for open source projects are ever changing and evolving, and while this means the best possible product every step of the way, there is limited compatibility between any two given steps.
XML is like violence. If it doesn't solve the problem, use more.
Just to give you an idea...
how often had you have something you wrote randomly segfault. Sure if it's a small program you can avoid it, but larger projects will have problems. Now go through the code for said large project, and have fun...no amount of comments will help find a misplaced pointer, missing malloc, etc. gdb on the other hand, will.
I'd say I must agree with this. I had a problem with compiling a certain version of GnuCash on my debian box a while back. Why? because some gnome library wasn't installed. I tried installing that, it required two other libraries...got them installed, and then the original lib couldn't find one of them (libdb I believe). So, I eventually said screw it, I don't feel like this crap and just apt-get'd the lot of them...
A stupid example, but a valid one. How many more people will instead of installing bins, install another OS?
Ok, so I like a little eye-candy, but a good UI, does help me getting the most from program.
It really doesn't hurt, that a program has a decent UI, and screenshots may tell me if it has.
'Everybody' likes screenshots, so I don't know why so few commercial Windows vendors, have screenshot URL's on their web-sites.
Another thing is, that when I shop around on eg. freshmeat, I do so, because I already have an idea about what I want. Having seen and tried so many programs over the years, just seeing the screenshots gives me a pretty good idea, whether the program fullfill my 'mental specifications'.
We don't have X on our servers, so screenhots doesn't help me that much, when I got a SysAdmin itch to scratch. (Well, I do like ncurses based UI's). So binaries, especially RPM's, since we run Red Hat, works for me, as the mighty, mighty CLI's equivivalence of screenshots.
It is not that source is hard to compile or install (usually), but it is easier for me to browse the RPM, to see, what goes where, and what kind of pre- and post-install scripts are executed, than looking through the makefile.
In short; binaries, makes it fast and effecient for me, to test, whether a program is
suited for me or not.
But in the end, the developer(s) has the final word; not releasing binaries, and expliciting saying so, gives everybody a clear message.
Some projects does seem to have a phase, where releasing binaries is a bad idea.
A binary becomes a fix-point, and if the project has potential, people _will_ start using it, and
then they start to to ask questions, on how and why, and etc.
On the other hand, if people have a good project, releasing binaries, may propagate it:
Word of mouth, or usenet recommendations are powerfull advertising tools. And a strong userbase, usually means, that some people will contribute back to the project, in form of patches etc.
>you can't beat ./configure and make install.
When "make uninstall" is just as common and easy I'll agree. As it is, when I install things from tarballs, I just make a text file out of the crap that scrolls down my screen. Uninstalling using this text file is a PITA and may not get everything. I tried installwatch a couple times but when installwatch dumps core half the time its rather useless.
It really depends on who you are targeting. Most of the time I consider myself and end user. Very rarely do I take the role of developer (lack of ample time to contribute meaningful work).
;)
"Who is your audience?" is the question that should be asked. If you want this software to be used by Joe Monday, then by all means establish a binary download. Generally, binaries are a nice hassle free way of using a slice of software from the net.
If your target audience is composed of very capable individuals or developers... then perhaps a binary distribution isn't really needed.
Packaging varies depending on the occassion.
Depending upon the occassion wrappings for presents tend to be diffferent (ie christmas as opposed to birthday presents). So maybe your open source gift is special and requires that little extra work... or maybe it deserves as much packaging as a piece of gum.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
But, it's probably still a good idea to have some sort of visual representation of you application, because a picture is worth a thousand, million, billion words (billions and billions). If your application doesn't have a UI, it still might be nice to show flow-diagrams, graphs, etc. to help the users/developers gain a better understanding for how the application runs.
It will help during the development phase in shortening the learning curve in understanding the application and getting up to speed on the object/functionality of the code pieces. It will also help in the "selling/marketing" phase by providing easy to understand representations of the application so that the user evaluating it can quickly discover whether it fulfills his or her needs.
--
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
My workplace seems to like it. Yes, they are backwards hicks.. their testing software is written in QBasic.
:P
Who needs binaries when we can use such a wonderfully wonderful interpereted language like that?
Another reason it's important to be able to see screenshots is because I, like many others I'm sure, often am simply seeking out a tool to do what I want that is better than the one I'm currently using. I really like most of the tools I'm using, but there's always room for that Killer App(tm).
Just take icq or even jabber, for instance. There's a number of clients out there, but do you really want to download, compile (if necessary), and install each and every single one of them?
A quick visit to the site, review the features, see the screen shot, on to the next site.
-- naChoZ
"I can be self-referential if I want to," said Tom, swiftly.
I try to compile as much as I can for the specific platforms on which I'm installing. It has been my experience that a custom build can perform significantly better than the distributor's stock build. However, there have been times when I actually wanted binaries instead of sources.
Sometimes it's because I felt lazy and didn't want to compile a large system. Mostly it's because I needed to run on a non-Intel system with no build tools. Many UNIX systems do not come with compilers (e.g. Solaris, IRIX). You must purchase them separately. In such cases, binaries are the only way to go if you actually want to get anything done.
Another thing to remember is there are over 6 billion people on this little planet. We all have different attitudes, approaches and agendas. Many people don't want, need or even care about manually compiling source packages. They just want to plug something in and go.
In an ideal world we might all build sources and use packages custom tweaked to our specific systems. In reality however, there are many places where binaries are just plain necessary. Of course, necessary is a subjective term.....=)
Its not difficult. its the time.
...
Try mozilla. try mico. They take AGES to compile.
Grabbing a binary is just for your convinience
Samba Information HQ
You should really post screenshots if your program will do the way cool kind of things that are nowhere else to be seen! (like textmode quake, or your half transparent MP3 player :-)
But if it's only your console based editor with auto-indent - don't bother because you're not cool..
--[rosso bright]--
Many of my tech-friendly friends have installed linux, but lacked the programming skills to install a lot of the software they wanted.
./configure, make, make install (or close, just more README.INSTALL or something).
I don't know about that man - anyone I have ever met that I would classify as "tech-friendly" have had a problem figuring out
... because I allways don't have the latest X, Y, and Z libs required to build from the source. It saves me time of having to fight the compile process.
:-)
There are 2 things that turn me off from helping open-source projects:
a) The quality of code of most Open-Source Projects, is just crap*. I'm NOT going to maintain someone else's goobly-gook! Sure it compiles, but if I have to spend hours scratching my head what the code does, it's probably faster for me to just re-write it. What's the benefit in that??!
b) If I have to fight the compile process. I should be able to just do: "make install"
If I can't jump in right away compiling the code, well, that decreases my enthusiasm.
I'm less fussy about binaries. Binaries are a nice touch, but I can live without them, if need be. But don't forgot, not everyone who downloads your project has a compiler !
Having screenshots is a way to show off, what the project has accomplished. That's not a bad thing. A picture is a thousand words
The first things I look for when I come across a project is:
a) FAQ. Does it explain and answer the most common questions?
b) Screenshots. (Even if they are trivial!) Does it make me go, "hey! this is a neat little app."
Oh well, this is just my opinion.
--
* I'm really sorry if this comes off as a flame/troll. But after coding all day, the LAST thing I want to do when I come home, is try to figure out someone else's poorly written code that was thrown together by some 3l33t 4@xor!
In general I agree. Although "by day" I'm a software engineer, I have a reputation for having something of a "reverse Midas touch" for new software -- I tend to find bugs in anything I touch. Occasionally something in OSS will pique my interest enough to download the binaries, and give it a whirl, and then give the developers some (hopefully) constructive feedback based on having been tinkering with computers since just after Neil Armstrong made "one small step for man, one giant leap for Mankind". However, I definitely don't have any spare time to waste on having to compile source code, and so won't fiddle with something that's not available as a binary. (The installation package is, obviously, one of the first places to find bugs! :-)
I am a user. My box is bad. It has 48MB of RAM. My Hard Drive is 2.5GB. It has 800MB free. My processor is 166Mhz. Compile big software project != good time for me. In fact, some things won't compile. Like ACE, GNOME, Mozilla, or anything using C++ + lots of components. Compiling ACE needs over 4GB of tmp space, and almost 1GB RAM. So, nice precompiled binaries help us less fortunate children. I have nothing wrong with source, in fact, I have used apt-get -b source program several times, and have use autoconf / make, and in extremes hacked makefiles and / or wrote makefiles for software. It is painful. Here is some advice: sometimes even programmer don't want to write a make file for your program. If you don't use autoconf, at least write a nice Makefile that needs very little modification to get it working if you want more than 3 people to use it. It is painful writing makefiles when you have no clue what needs to happen...its all trial and error. And, if you know how to compile it, then compile it and make a deb or rpm or it.
I like apt-get -b source because it can install stuff that won't otherwise. Like dfm + woody + helix(I know I'm evil). Well, helix created a package conflict, and dfm cannot be installed. It is small enough that the compile was fairly quick for me(10 minutes). That is what I have no problems with -- small, less than 5MB of source applications. I don't need binaries for those. But, if you make some l33t 31337 40MB hello world program...GIVE ME A BINARY OR I WILL TRACK YOU DOWN AND SHOOT YOU.
EOR -- End Of Rant.
My karma just went down. I was so close to the automatic +2...
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
If all-caps posts can be 'banned', I strongly suggest somebody with admin priveleges on slashdot visit this link and add the damn link - Oog was way more funny...
There are two reasons this is an issue - one is that stuff ships that really _doesn't_ compile (sad but true...). The other is that stuff ships that the original author got to compile, but it doesn't necessarily mean that anybody _else_ can get it to compile, and it needs to get kicked around till the dependencies are identified and it does become possible for somebody else to compile.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Also, if your project is the type that writes the documentation after the code (instead of before, which is my preference), screenshots may be the closest you've got to user documentation other than whatever level of obviousness exists in the not-yet-completed menus of your alpha-level product.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Heck even ABNORMAL users won't want to compile anything. When I look at new apps for linux I do the following.
1) Look for a binary package.
2) Hope there's no dependency problems (for good enough apps I'll solve the dependancy problems).
3) For really, really cool apps. I'll get source if thats all that's there.
4) If the source doesn't compile I will try to fiddle with easy to solve issues for an amount of time directly proportional with how much I want to use the software.
I don't have the time right now to contribute to Linux software in any way but testing right now. However, I do concur with the statements about bad bug reports. Unless its real clear and real repetable and not a library issue (and they don't already know about it) I generally don't send off bug reports.
Hmmm,
./configure which is likely a shell script. Well, I asume its bash, and I have it. At least it is sh compatible?
./configure; make dept; make install;
You are sure this works in my home directory?
What programming language do you use?
Do I have it installed?
Which make do you use? Do I have it?
It even starts with
Tzzz....
Either you make a RELEASE or not. If it is a release it has to include binaries. Or call it not a RELEASE.
Any pre-alpha source ball is something which is either for the avangard user or for the programmer only. I would never call this a RELEASE. Its a sample or a prototype but not a release.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Hmmm, I consider my time to valuable that I dare to download mega bytes of sources and compile them to find out that I'm neither interested in using the program nor in contributing to it. ...)
....
(90% of the precompiled stuff allready is useless and downloading it wasted my time
For me it is encauraging to see how it looks and to try it out.
Why should I contibute to a project I dislike because of its "look and feel" and/or its odd way in doing things?
And why should I have the burdon just to find out that I dislike it?
If you like me, to use your stuff, convince me it is usefull and if you like me to contribute, prepare it that a contribution seems worth for me.
Well,
as you see a lot "I" and "me", but thats how it is.
Just my 2 cents
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There are some things the open source community will have to realize before it has any chance of getting the home users, and pushing MS out. First of all, most users are dumb, they want everything to be easy. 2nd, people like pretty things; they love the Windows interface and they love the new MacOS X candy interface. As good as Gnome is, its interface isn't anywhere near as pleasing as Win and Mac.
I'm getting off-topic here, but something else Linux and the open source movement need is support from commercial software makers. It's indeed starting to grow, but until titles like Photoshop (yes, I know, there's Gimp... but it's not the same), and Office for that matter, are ported to Linux most apps will be too hard for the common user.
On the other side, commercial software makers should learn the value of sharing code and relax on the greediness. This would only improve customer satisfaction and the 'likelyness' of companies.
All that aside, merry christmas everyone.
http://www.logient.com
PR1 was advertised as "beta" software. Their mistake was calling alpha software as beta.
well perhaps by calling it "beta" they attracted more of a "finished product" crowd than they normally would have, but it still proves my point: releasing alpha software in binary can have a negative effect on interest level of that software.
- j
this sounds like a good idea, but we're talking about alpha software here! do you really want people who need to be enticed by binaries to be running alpha software? sure they may not be able to compile it, but by the same token, they may not even be able to run it!
i would think the fear of releasing a binary "too early" would be that you run the risk of turning off a lot of people. remember the response when Netscape released their PR1 version of their browser? i know people who wrote them off forever for that, despite my attempts to convince them that the Mozilla nightlies are coming along nicely.
i would still argue that keeping it source-only would be best. though i fail to see the logic (from the original article post) of why screenshots are bad. i would like to think that you entice people with pretty screenshots if you're going to entice them with anything. but alpha-code binaries? that seems risky.
- j
Well, strictly speaking, all files are binaries. Walco
I don't agree, I don't see why the developers wouldn't compile binaries for all platforms the project is supposed to be released to, that's just a matter of a few compiler options anyway.
Now, if you use exotic OSes such as Xenix or Unixware and expect Linux projects to be ported to your platform, yes you're a second-class user, but that's your own choice, isn't it ?
"Naughty, naughty, naughty, you filthy old soomka !"
When I'm debugging someone else's code, the most useful comments are things at the beginning of files (e.g., ``This is an FSM implementation of a lexicial analyser'') and before procedures/functions/subroutines. We've all seen the canonical bad comment (i = i+1; // Add one to i), which documents what is happening on a very low level. What we really need to know is why things are happening, and which domain constructs and concepts are involved.
Once the programmer has enough of an idea of what a particular module is doing, the code should be reasonably obvious. Comments should note things like assumptions (``This subroutine assumes that its argument is a valid list''), things which need doing (``ToDo: check for invalid arguments''), or domain-specific things (``If the wibble isn't gromitted enough, we can't proceed with the gizmo, so we burble instead'').
Source code is for communication between people, after all (otherwise we'd write in machine code), so it should be written with the assumption that both the programmer and others will read it at some point. Today's Astonishing Hack is tomorrow's Nightmarish Muddle. If you think that your code isn't ever going to change, you're wrong; it'll either adapt or die.
Just my 2 dimpled chads,
Stephen
Compiling doesn't have to be all that bad... what really sucks is that software requires you to have a bunch of stuff installed before the compile process. It's bad enough installing a RPM and finding out there are failed dependancies. Having a compile fail partway through is even worse. I don't bother downloading source anymore because more often than not I'm missing something it expects me to have and I don't have all day to spend getting the stupid thing working. Developers should package as much as they can with their code... so that users don't have to go on a wild code goose chase to install their products. Sure the downloads will be bigger but many people have decent connection speeds these days. (Most) windows applications follow this rule... packaging required DLL's for example... just in case they are needed. This is part of the reason Windows apps are (usually) easy to install.
Blender And Linux Fan
screenshot looks cool? Download. Is there an RPM of an EXE? I'll try it.. I'm only a pseudo geek.
> ban the dumb link
I second the motion.
Won't we get all the trolls voting dozens of times if that happens?
What Linux definitely needs is a universal installer similar to those known in the Winders World (see InnoSetup for an released-source example).
This would get us away from that
So, before publishing any binaries, publish the tarball for a fairly universal installer (less<README, ./configure, make, make install). And, yes, add some screenshots, willya?
Use The Source, Luke!
I think that both binaries and source packages are equally important in their own ways. From an end-user standpoint, binaries (RPMs, Debs, etc) are more important because they make the program easier to install and use "out of the box". Also, binaries allow programmers to see how a program is *supposed to work* (or not work(!)) before they begin hacking and compiling the sources. Binaries are also significant when it comes to conviencence. For example, many people download quick RPMs for simple non-critical programs such as instant messangers or Web browsers, but nearly always hack and compile sources for all their most important programs.
-----------------------------------------
Perversely greped and groped by PowerPenguin
Or he built his compiler on a different machine
t
1.0x10^-57% complete...
t
If I can't get the program to compile, I download a binary. I'd say that 90% of the binaries I download work.
When either of these do not work, it is usually for the same reason, library incompatibility.
I do not always have time to hunt down new (or old!) versions of libraries, or make links to them if they are located in different directories than the programmer expected.
This could be eliminated if developers would make staticly linked binaries availible. They would take up more space, but they would work.
"Reality is less than television."-Brian Oblivion
More to the point... what would you have compiled WITH?? Hard to compile an OS or compiler without a binary OS and compiler...
sig fault
Yes, you have to read the damn docs, yes, you have to learn how to do certain things, tough...
And you complain that Windows is on 98% of desktops.
DAILY ROTATION
As for screenshots, some projects obvously can't really benefit from screenshots, like the Linux kernel, but there are a lot of projects with "great 3d engine" that turn out to be basically Galaga in OpenGL with Tux as half the graphics. A screenshot can give you a clue as to whether the programmer understands gameplay and design, or just likes programming matrix math.
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
I strongly urge programmers to avoid releasing binaries before their code will compile. Doing so is liable to result in a flood of unhelpful bug reports, such as "The ****ing thing won't run!" and "You said this was the binary, but you gave me a 0-byte file!!".
(If you can't
./configure
make
then you probably shouldn't be using pre alpha code..) The theory is that people with the skill required to compile can cope with small errors, and read the documentation instead of filing too many bug reports.
Now, once it's at the "Beta" stage, perhaps binaries?
Screenshots are probably a good idea at an early stage, though. Gives people a feel for what your program actually does before they invest time downloading / gettting it going.
Java could be considered a uncompiled binary as well... The program isn't natively executable and either requires compiling for whatever platform it's running on, or be run interpretively.
I used up all my sick days, so I'm calling in dead.
Is there any problem with releasing both. I'm sure most people would like to try something before they decide to contribute. I personally find it a lot easier using precompiled binaries. Isn't the software there for both contributors and the public. What's the point in making software, if only a few contributors are going to use it? Precompiled binaries are also a lot easier for newbies, and could introduce more people into contributing to the development of the software.
That way, people who just can't/won't compile something theirself can still get it, and everyone else (including those who might want to tinker with the code) will download the source.
Seems like a mostly win-win to me.
NightHawk
Tyranny =Gov. choosing how much power to give the People.
Frequently I just want to try out a program to see if it would be useful for me, and I don't want to have to fiddle with it to get it to compile. Do you think I'd want to have to compile mozilla every time I get a new nightly release? Of course not! I just don't have time to screw around and tweak with every little piece of software that I might use. Sometimes I really want to get into a program and change it, whatever. Call it the "scratch an itch" syndrome, fine, I do it because it interests me. But most of the time I just want to install something quickly and then use it, not fiddle with it to get it to work right. I don't have the endless free time. That's why pre-compiled binaries are useful to me.
Binaries are good if you just want to test out the product and see how it is. Since Linux is trying to target newbies and home-users, rpms, debian packages, and the like are good for those kinds of people.
If the users have enough knowledge and want to customize the source or recompile with different libraries or what not, they can use autoconf or change / view the source code to do different things or even see how something is done in case they want to use a similar concept in their programming.
Personally, I like srpms because you can still modify the source code but keep an inventory of software installed via the system rpm database.
On the note of screenshots, I like to see what the program looks like a lot of times first before I try it so that I know what the program is capable of (as far as UI goes) and for visual appeal: I think a good-looking program is easier to use (not necessarily better) for newbies than some hacked-up Tk program.
and lose any hope of your software catching on with the general public.
NO NORMAL USER wants to compile their applications from source if they don't have to. Most users don't even know how.
Screenshots as well. Nothing "sells" a program to a user like being able to see it in action.
Try using words to describe Enlightenment to a user not familiar with window managers aside from those from M$.
Then show them a screenshot. "Ooh, sexy!"
Binaries and screenshots are a necessity for getting Joe User to download your app.
-the wunderhorn
Karma: Bored. (Thinking about resurrecting the "Anyone else is an imposter" joke.)
Once you get into doing binaries, then some wussy boys will whine for rpms, then some want debs. It gets to be a real pain. I guess if you are at beta stage, do binaries, alpha stage: no. Screen shots are your biggest salesman, though.
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
No! No! Not THAT kind of binaries! We mean working programs not alt.binaries.erotica.pictures.
Little Brother, watching the watchers
I think it's worth mentioning that coders are not the only ones who contribute to an open source project. The critical part of an application is not how it is coded; it is the final user experience. Released binaries means more eyeballs on the software, more bugs reported and more constructive suggestions on how to make the software easier to use. If you wait for software to be 'mature' before letting anybody play with it, you may find out that a helpful change is now very difficult to change because of all the dependent code piled on top of it.
As a side note, downloading the binary didn't end up fixing the problems...I transferred the frustration from compile-time errors to segfaults. I guess you're damned if you do and damned if you don't. Welcome to Linux.
Yes, we realize it's a trick. In the future, I recommend that you take the time before clicking a link to see where it's pointing.
goatse.cx is freedom of expression and that freedom deserves every protection possible. Sure, it's disgusting, but that's one of the prices you pay for your freedoms. If you want to attack the linking of goatse.cx, you're more than welcome to post your flames to the AC doing it. Asking for a more "legislative" solution is just a form of censorship.
Grow up.
I/O Error G-17: Aborting Installation
His solution solves your problem perfectly.
I/O Error G-17: Aborting Installation
If you feel offended by something you see, just walk away.
I/O Error G-17: Aborting Installation
<sarcasm>Really? I hadn't noticed that.</sarcasm>
The First Amendment is a guideline, and deserves more respect than your small mind can comprehend. Read my comment carefully next time and you'll see that I stated that quite clearly in my closing.
echo 127.0.0.1 goatse.cx >> /etc/hosts
Your problem is solved. Don't promote your brand of censorship on the rest of us.
I/O Error G-17: Aborting Installation
Now, what was your argument again?
I/O Error G-17: Aborting Installation
It sounds like we don't have the full context here. If the code is in a pre-alpha state, I'm not sure anything is gained from releasing binaries. If you're looking for feedback from average users, then you may want to compile it for some chosen users, who you know about. When the project is more mature, the issue is much different
Regarding screen shots. This has started to become silly. Every project should have a screen shot. Where's the screen shot for gcc? I'm sure it's coming soon. But there is a very good reason to provide them. At least they provide some visual cue to what the program is supposed to do, and what it's current status is. Many programmers seems to be to busy coding to just write down a few words about what the application is supposed to be doing. Instead they churn out Changelogs, with messages useless for a prospective user of the type: "Rewritten conl.c - Amiga compatibility", "Removed segfault in apli_susd() when receiving new susd's" and even posts them to the front page (as if someone were interested, if they wanted that information, they would probably get it from CVS). So, if you are too lazy to tell what the hell your program is supposed to do, then at least supply a screenshot!
Doesn't it come down to who you are gearing the current code towards? At first, you need coders to review, fix, and add to the code. Once you have some (somewhat) stable code that resembles what you want the end result to be, the binaries should be available for non-coders to do their thing with. There will be a period of time in there where it's not so black and white, and that is when the politics will get involved.
If the project is still pre-alpha, then it's probably a bit premature to have binaries around. The question is what your definition of "pre-alpha" code is. Binaries should be available when the code has stabilized enough to give the users of the binaries a resonable idea of what the end result is supposed to be.
"Bite me, it's fun!" - Crowe T. Robot
If your software will compile out of the tar ball reliably on RH/Deb/Suse and their derivatives then there isn't a need for binaries(Apache and Python are good examples). But if you depend on the latest version of a library like GAIM does, then Binaries are a must
(I think this is a troll, but I'll bite...)
Debuging info is NOT BLOAT, it's there for a reason. If you don't want it -- remove the -g from CFLAGS in the Makefile or you can even strip them out with objutils (?)
Furthermore, COMMENTS (?!?!?) are NOT BLOAT !!! Nor are they redundant documentation -- comments in code are explain what's going on in the code, where else is this info being repeated. In a college level CS class YOU WILL FAIL if you don't sufficently comment your code. Commenting code has nothing to do with how well of a programmer you are, even the best will groan at a qsort() with out comments. My motto is: legible code also includes comments !!!
"...through this door all my dreams come realities, and all my realities become dreams..."
well if you consider gdb useful yes.
"...through this door all my dreams come realities, and all my realities become dreams..."
As a somewhat long-time Unix user (c. 1987), I cut my teeth getting source-only packages to build. It was a great learning experience and I would recommend it.
But today, if I see a package that doesn't have a pre-built binary, I'm only about 10% as likely to go to the trouble of building it just to try it, especially if there aren't good screenshots or anything.
If the point of your project is to teach people how to run 'make', go ahead and skip the binaries. Otherwise, if you want your project to catch on and get used, post some binaries. If you don't, someone else will...
Normally takes about 7 days doesn't it?
Without binaries, if you're installing linux for the first time, how are you supposed to run it? =-) One little thing to think about...
"I have not failed. I've simply found 10,000 ways that won't work." --Thomas Edison
cry me a fucking river.
Well if you are a developer(for profit).... dont support them. See how far that river takes you.
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?
Yea, and the profit of the venture will never rise either, with that POV.
He meant screenshots.
Releasing binaries is good so that you can have more users. Releasing source is good so you can have more programmers. Where's the issue?
witty sig goes here
they can help you tell if it is what you are looking for, without having to through the time of downloading and compiling plus, even if they do give you bianaries, simetimes it can be hard to get running.
OK, who wants to distribute their code as several binaries compiled against libc, glibc, PAM, shadow passwd, RH, Slackware, etc.? (And possibly even Linux and Hurd flavors...)
Source is fine if you can untar it, type make, and go. Editing the Makefile is tolerable. Binary packages are good for complexicated things like Mozilla, which takes a bit of kicking to get in place, but this means there'd have to be a standard package for all distros.
The Way Not To Do It is to release a source RPM with no info on what order to apply patches in (or even if they need applied) like Red Hat 7.0. Sure, you've got the source... but do you know what to do with it? I don't.
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
Why is this post marked as flaimbait?
It makes a completely valid point in that as consumers of software we all depend on binaries particularly for installation.
Is it marked as flaimbait because it has struck a nerve in the moderators? Most people dont care about the source code when they install the latest mozilla, the latest gcc, the latest xfree86 - whatever.
I know that when i do a 'make install' in the ports collection in FreeBSD, it downloads the source and then makes it for me - i suppose optimising the compile for my platform.
For all I care, it could just download the binary and install that, saving me time waiting for the compile to complete.
Mod me down, but its a fact.
Anyhow, security was just an example. Suppose your first draft of the source code is just poorly formatted and doesn't have enough comments? Maybe you don't want everybody to get a bad first impression.
XP rule: all code is written according to a standard. So no, that's not a valid excuse. =)
I'm also a little lost as to the logic of your post. You start off talking about security, and then start talking about bugs. These are very different things.
Not usually. Look at any of the security boards... my estimate is that 80% of security holes are related to simple bugs, with the remaining 20% being architectural flaws.
If it is a simple bug, then my previous post applies -- why should it exist at all? If it is some deeper, "archetectural" level security issue, then it should certainly not be held secret with an insecure binary being released.
I can't imagine a person willfully advocating the release of an insecure binary without source for the purposes of fixing the insecurities in the background.
That's just messed up.
3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.
Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.
Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!
I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.
But that's not even the half of it.
My real question is this: Why are the bugs there in the first place?
I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.
The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).
Other XP tenets that would very much help here are:
I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.
None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.
I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.
- Dr. Barson
Anyhow, security was just an example. Suppose your first draft of the source code is just poorly formatted and doesn't have enough comments? Maybe you don't want everybody to get a bad first impression.
I'm also a little lost as to the logic of your post. You start off talking about security, and then start talking about bugs. These are very different things. I agree with you that there is no excuse for a professional programmer ever to write a dangling pointer. (But I'm speaking as an amateur programmer :-) But I don't believe that it is possible to write a program that is perfectly secure the first time around, simply by following good design principles. The history of cryptography is littered with examples of supposedly unbreakable codes that were subsequently broken. Also, writing code that doesn't crash is an absolute, but security is never absolute. There are always trade-offs between security and other desirable features.
Find free books.
"good thing(s)" is a registered trademark of Martha Stewart (herin referred to as "client"). We are asking you to refrain from using "good thing(s)" in your title/headlines as it is the sole intellectual property of said client.
We hope you will move swiftly to correct this matter.
With best regards,
Jockoby, Sloan, & Jockoby
Build Your Own PVR/HTPC news, reviews, &
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.
Should use of open source software be limited to those with enough programming familiarity to be able to run 'make'? I would hope not -- everyone should be able to reap its benefits, whether they're capable of contributing a bugfix or not.
-Poot
If the software is still not mature enough to be useful to joe avergeuser then the idea should be "If you can't figure out how to compile this its probably not going to be useful for you and going to break so much you don't want to use it." Developer releases should be for developers.
My time is valuable, I will not download software that needs so much attention: Download, compile, oopps! wrong version of library, etc...
Don't he mean snapshots, not screenshots? As in CVS? I'm sure cvs access will lead more people to code than how tricked out my enlightenment desktop looks.
--
--
Society has traditionally always tried to find scapegoats for its problems. Well, here I am.
It is just for commodity. The developers can then drag many more users and feedback. And since everything is automatized, this doesn't require any effort.
You're a troll.
Go away.
Your post didn't even make any sense.
It's often quicker and easier just to download the source and build the thing than upgrade all the libraries on my system - which already works satisfactorily (so I don't really want to upgrade). It seems to me that you always need a distro less than 3 months old on your system to run precompiled binaries of most things.
Having said that, I'd like to see both binaries and source out there. When I *do* have a new distro, I prefer to download binaries!
Oolite: Elite-like game. For Mac, Linux and Windows
I seem to recall that this was also true of BASICA and/or GW-BASIC for the PC. The "save" command had an option to save the full source, but it was not the default.
---
where there's fish, there's cats
Like the screenshots for xftp and xmftp? Fun fun GUI ftp clients...
-- Greg, missing the WPS.
I think everyone knows what a blood snapshot is...but do you know what your talking about. The question asks about screenshots
Oops....you'll know what I'm talkin about in a bit.
No binaries or screenshots are dumb. (got the attention... ok, here we go: )
I love open source simply because of the freedom of it. I've never contributed to a project, simply because I lack the knowledge yet, but I love knowing that I do so many different things with the software I download. I don't have to worry about paying money for software that I'm really not completely satisfied with (taking away precious tuition money), instead I know I got something that was born out of people's volunteer efforts. The people that make these programs do it because they want the program to be good, not because of any business presures.
Because of this, it seems backwards to require that people download the source only. Granted, this is completely within the project managers' rights, but it just seems contrary to the nature of the product. Requiring people to download the source is simply a restriction, not a freedom. Freedom is letting people do what they want. If people want to use the software only, and not contribute, then why would you want to cut those people off?
Same with screenshots... it may seem so superficial, but that's the first thing I go for (right after a description of what it does). I know what I need in programs, and one of them is a UI that means I can do my work quickly and efficiently. Not having screenshots doesn't even make any sense towards the getting people involved thing; what good will not letting people have screenshots do? I think his reasoning is that if you're at all interested in this program, even seeing what it looks like, then you should have to go all the way and download source code, take the time to compile it, then you can see anything you want. The next step would be taking any sort of description off the webpage and making people download the source code to look at the comments inside to see what it does.
Seem extreme? What're you doing on a lesser scale when you remove things that make it easier for people to get into project? (which by no way means programming... how many times have I heard that the best way to start helping is with non-programing tasks, faq, documents, etc?)
Of course, I really don't have the soapbox to stand on, never having been in his place. But as a person on the other side of things, this is definately what I appreciate about projects.
You f*cking americans are so arrogant. You presume your laws are respected (or even applicable) 'universally', wheras in reality they dont apply outside your own borders, let alone universally.
Grow up, and you can stick your 'first ammendment' up your arses.
Oh, and by the way, perhaps you'd like to explain your attitude towards global pollution control, too?
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...
Its not so much a matter of difficulty as it is time. I dont know about you but I dont have a day and a half to compile X or kde or whatever. another advantage is that you can compile libraries into the binary , so you dont have to force people to download the libs on top of the download for the program
My motto has always been (if I am interested in helping) 'If I can't compile it then forget it.'.
Now for non-developers who might be interested in using the software... snapshots are nice (mozilla nightly builds come to mind).
I miss the Karma Whores.
I dont know much C or C+ but its cool to look at what people made and every now and again when i am not drinking I can actually understand what is going on in the program. I LIKE IRA GLASS
I never said this was the solution (or even a solution for that matter). I simply pointed out that 1st am. rights don't apply here, when s/he for whom my response was starting crying about 1st am. rights. You are, in fact, prooving my point.
Blah blah blah blah.
Freedom of expression does not apply here. This is not a public area/site/whatever the hell you want to call it. It is a private site run by the runners of slashdot. If they want to ban stupid links, it's their choice. If they want to ban you, it's their choice.
You're not protected by the first ammendment here; this site is not run by the government for the people. It's run by certian people for certain other people.
You think it'll hold up in court, for example, that those who run this site banned you from posting a specific link on their site? Please...
And second, censorship is not the problem. Unwanted censorship is. If you want to censor something, go for it. If someone's pushing censorship on you when it's unwanted, however, then it's a problem.
No, governmental laws may not apply here...
And yet you claim first am. rights here? Ha. That's funny.
Yeah, but then again can you imagine what the trees would look like, if there were precompiled binaries?
. 18/i686/rtl8139/via82cxxx/nvidiavanta/noscsi/...
sound appetizing?
Does ftp://ftp.us.kernel.org/pub/linux/kernel/v2.2/2.2
The application domain determines the significance of binaries and screenshots. The type of application determines: 1) Who uses it 2) How they use it 3) What form of GUI they want Webservers are notorious for not needing screenshots, since they are run by the technically knowledgeable administrators. Conversely, creating graphics programs absolutely REQUIRES screenshots. For the first example, even the finished product may not necessarily be compiled to binary, while the second usually is. This extends to various domains at various levels. It all depends on who the end user is, and what his level of expertise is expected to be. You write letter and e-mail to someone in particular. Why shouldn't you write code to someone as well?
Mod me down and I will become more powerful than you can possibly imagine!
I know plenty of people that, while interested in open source programs, couldn't care less about programming and many don't even have a C compiler (or don't know if they have one). open source software doesn't just benefit programmers, it benefits all users of that program because of it hopefully superior design and clean coding.
The global economy is a great thing until you feel it locally.
You ranting Linux Zelot! Are you so pompus to think that by being "uber" you are the only person who deserves a stable OS.
Jeeeebus!!! What if the people who designed electronics thought the same way as you. You wouldn't have a computer to be so uppity with now would you.
What if the people who grow food decided that "If you can't do it from scratch I'm not going to help"
It'sjerks like you that give Linux, Open Source, and computer useres in general a bad name.
Get off you soap box and help a newbie!! You never know, the kid you help get started today may be the Linus of tommorow.
Pompus jackass!
but seriously folks, screen shots are VERY useful for software testing, especially GUI intensive apps. Bug reports have to be detailed enough to communicate the problem as well as how to reproduce them. "A picture is worth a thousand words," so it sure saves a lot of typing in the bug tracking system!
I don't know anything, I'm just trying to get Karma to mod bitches like you.
I suppose the solution would be to only allow a limited number of programmers to attempt modifications. Slashdot moderation, perhaps?
The most brilliant aspect of Bradbury's Farenheit 451 (and I'm not particularly a Bradbury fan in general) is that he presented a future in which books and other forms of speech were banned NOT because they government wanted to control the people, but because the people WANTED the government to ban these books because they made them feel uncomfortable.
Don't you see that parallels between that and what you are trying to have banned here on Slashdot?
And yes, I too realize Slashdot is not a democracy, but considering all the lip service paid to freedom of expression by the editors, it would be really hypocritical of them to start banning links, don't you think? And besides, this is the sort of thing moderation was invented for. If you don't like the current moderation system, attack that, not individial posts or links.
When i started to use Linux in 1997, as a major newbie i tried Redhat linux 5.0, it was easy to use, and i loved rpm, but after evolving the past years, i like the power of the source, you know, patching it, compiling it, make it "your own", so my natural path was to go from redhat to slackware.
'I sense much NT in you. NT leads to blue screen, blue screen leads to downtime, downtime leads to suffering.' -Uknown
Taking on a champagne-open-source view (a la ESR), it seems to me that a potential developer of a program must first become a user - with which precompiled binaries can only help. If a user then decides "yes, I like the way this project is going, and I think it should have these features, which I can try to implement myself because I'm a hard-core coder" (or some equivalently motivated mumbling), then he will download the source.
Of course a more realistic model of the situation would include the type of a user's system: a deb/rpm based system or not, since those using a package based system might like to keep their system as consistent as possible. My system being based on rpm, I would look for the binary rpm first, then the src.rpm (which, if there's no rpm, is unlikely to exist), then the tarball (in which I would hope contained a project.spec file for compiling my own rpms!).
A user whose system was not packaged based might not care as much, and in fact feel that he should compile projects himself and have an archive of sources of all the downloaded apps he has for his own consistency purposes. But then, to such a user, it woud matter not whether the binary was available or not.
So my vote? Binaries: yes.
-Terence
Haskell, the static-typed, lazy, polymorphic, programming language.
I guess what they say is true -- every sheep needs a shepherd. Why is it necessary for you to reiterate what this crowd's common sense is already telling them before they believe it? Thanks for reigning in the /bots (for the millionth time)...
"Watch these suckers jump when I get root." - l33t j03
$ man strip
"Watch these suckers jump when I get root." - l33t j03
Save bandwidth, keep the screenshots coming. If it is early code, and the install amounts to anything more than: tar zxvf pacakge.tar.gz && ./configure && make && make install (without lots of weird dependencies) I want BINARIES, dammit!
"Watch these suckers jump when I get root." - l33t j03
You didn't properly specify the filenames of all those loadable modules, dude. Next time, instead of incorrectly listing them as a single directory path, put a *.o extension on each one.
Except the first few top-level parts, which are directory specifiers.
Hay thar.
Bradbury didn't 'present a future.'
Bradbury told a story.
There's a big difference: he was able to make up whatever he wanted, without regard for reality.
Hay thar.
What's the point of re-compressing a compressed .tar.gz archive? ;-))))))
A binary would work better
Binaries :1 -
Source : 0
-- Life wasn't meant to be easy...
What I really would want for all linux apps, was a standard graphical installer like they use in Winblows, but instead of just copying files, the installer should also compile the source files and let me choose where to place my binaries.
This would provide the best binaries for my platform, access to the source files and an easy way to install the application.
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!
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.
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.
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.