There is no one definition of success for an open source project. Anybody who starts one should have some goals in mind (e.g., hack on cool code, make something which solves a problem for me, make something which is used by 100/1000/1,000,000 people). Success is meeting those goals.
Here are a couple of examples.
I wrote GNU/Taylor UUCP. When I started, success for me was to develop a UUCP package which would be widely used by people without the money to spend on AT&T UUCP, and to be the premier UUCP package on free Unix systems. I met those goals.
I was the GNU binutils maintainer for a few years. During that time, success for me was providing, on multiple platforms, 1) an assembler which could handle whatever gcc generated; 2) a linker which was compatible with the system linker (on a non-free Unix system), and was faster; 3) tools which were very fast on free operating systems--specifically, much faster than gcc so that they were not the bottleneck for development; 4) adding full support for shared libraries. Those goals were only partially met--on Solaris, in particular, the Sun linker was better.
If you don't have any goals, then you can't succeed. If you can't measure your goals, then you can't know whether you have succeeded.
Well, but, 1) Descartes was wrong; 2) even if he were right, a computer program could have sensors which are quite a bit more accurate and wide-ranging than human senses (after all, we already use technology to extend all of our senses), so does that mean that such a program would have a consciousness more real than human consciousness?
And, although I don't have a convenient link, neither was Hussein. The Baath party took power in a coup, and the elections held since then have been a sham.
Wired had a good article about this guy a couple of years back.
Re:The open relay testers send me unsolicited e-ma
on
ORBZ Shuts Down
·
· Score: 2
To me, spam is unsolicited e-mail. I don't know what sending in bulk has to do with anything. I just care about what winds up in my mailbox.
You're right in that I should have just refused to accept mail from ORBZ. Unfortunately, doing so would have caused me to be listed in ORBZ, and thus caused others to not receive my e-mail. Catch-22: refusing to accept spam would have caused me to be labelled as a spam generator.
My main point, from the post which started this thread, is simply that I believe that ORBZ was acting in a hypocritical fashion, which is a risky position from which to take a moral stand.
Re:The open relay testers send me unsolicited e-ma
on
ORBZ Shuts Down
·
· Score: 2
It seems to me that a spam e-mailer would make similar arguments. ``You get e-mail you don't want? That's your problem.''
What's the difference?
Is the difference just that ORBZ e-mail testing is good? What if I disagree? I'm sure some spammers think that their e-mail is good. Is their spam OK? Why is ORBZ right and the spammers wrong? Either way I get unsolicited e-mail in my mailbox.
Re:What makes you think they are testing?
on
ORBZ Shuts Down
·
· Score: 1
I think they were testing because the messages came from the ORBZ machines.
Re:The open relay testers send me unsolicited e-ma
on
ORBZ Shuts Down
·
· Score: 1
Sending double-bounce messages is a feature, not a bug. I would be happy to hear an explanation of what I should do to ``fix'' this with respect to ORB* messages.
And in what way was my argument a strawman? Read it again. I didn't say that the ORBZ messages didn't say what they were. I said they didn't tell me specifically why they were testing my server, and I said that they didn't tell me how to prevent receiving those messages in the future.
The open relay testers send me unsolicited e-mail
on
ORBZ Shuts Down
·
· Score: 2, Interesting
When one of the open relay testers decides to test my systems (which have never been open relays), I get at least a dozen unsolicited e-mail systems double-bounced to me. Isn't it strange that a system created out of fury at unsolicited e-mail generates a fair amount of it? The double bounce messages never tell me specifically why they have decided to test my system, and they never tell me how to prevent them in the future. Shouldn't people on a moral crusade be careful about hypocrisy?
Sure, modify/etc/rc.d/rc or/etc/rc.d/init.d/functions. If you look in the latter file on Red Hat, you will see that it sets a number of environment variables.
Lessig isn't saying that all music should be free. He's saying that there needs to be a balance, and that right now the balance has shifted too far toward the copyright holder.
One can imagine an idealized society in which law does not regulate the ability to communicate.
Back in the real world, however, the U.S. government bans certain types of speech for reasons of obscenity (e.g., child pornography), or for reasons of public safety (e.g., incitement to riot), or for reasons of consumer protection (e.g., truth in advertising), or for reasons of commercial value (e.g., DMCA). Not to mention the classification of information for purposes of defense and protection of political reputations.
Those restrictions will change over time, but they are not going to all go away. People who live in the real world need to consider how they should be applied. Just waving them away as philosophically inappropriate means that you can't separate the bad restrictions (IMHO, DMCA) from the good ones (IMHO, truth in advertising).
There may be no digital divide in America, but the focus of the Advogato article is on other countries. There is certainly a digital divide in the world, and there are plenty of people who can not afford a PC no matter how hard they work.
Forever War == Starship Troopers after Vietnam
on
The Forever War
·
· Score: 5, Informative
I think the comparison to Starship Troopers is reasonable and appropriate. Starship Troopers was written during the Cold War after World War II and the Korean War, and it reflects the sensibilities of the time (plus Heinlein's own philosophy, of course). I think the Forever War is a conscious updating of Starship Troopers after the country's and the author's experiences in the Vietnam War.
BTW, Haldeman used to teach a science fiction class at M.I.T., and for all I know he still does.
The hardest part of programming is debugging, . . .
That should be true only if you don't design it well and don't use reliable programming techniques.
Do you say that based on your experience with large multi-developer programming projects, or do you say that based on books that you have read? I genuinely want to know.
My statement was based on many years of experience with multi-developer projects, both free and proprietary.
In my experience with software projects, a straightforward build system is essential. It permits consistent builds, which is essential for debugging complex problems. It permits easy builds, which is essential for developer testing. The hardest part of programming is debugging, and good debugging requires speeding up the edit/compile/debug cycle, while ensuring that everybody still gets the same result for each build.
So I would say that no matter what, you should improve your build system.
Given that, should you use the GNU build system, which is autoconf/automake/libtool? Well, it depends. There is a definite learning curve to these tools. They are written in several different languages (sh, m4, perl) and dealing with certain problems can require understanding each of those languages and how they interact. Using these tools will not automatically make your code portable or easy to build; you have to use them correctly, and you have to understand what you are doing.
On the other hand, every other system which supports a complex build process also has a steep learning curve. There's no easy solution--if there were one, everybody would be using it.
The GNU build system is widely used, so there are a lot of people who can help you with it. The mailing lists are active and helpful. There is also a book, but I'm one of the co-authors so you'd better take that with a grain of salt.
I've converted large projects from ad hoc build systems to using the GNU build system. It's usually pretty straightforward--a matter of a week or so--but then I have a lot of experience with the tools.
I've never used most of the other build systems (e.g., Odin, Jam, ANT) for a serious project, so I can't honestly evaluate how they stack up. I can recommend against imake.
As a co-author of a book about Autoconf and friends, I obviously disagree. I don't know why you have trouble using autoconf on Plan 9. I'll just note that I've used autoconf on Windows with the Microsoft C compiler, and it works fine (autoconf does require cygwin to run on Windows, but the programs I built with autoconf did not).
You are certainly correct that autoconf is not going to prevent anybody from writing bad code, such as code littered with #ifdef statements. autoconf is a tool, and it's quite possible to use it poorly.
When you use the AC_CONFIG_HEADER macro, as almost everybody does, autoconf does pretty much what you suggest: the main difference is that it writes a single header file to disk, rather than many small header files.
autoconf normally only changes the Makefile to handle things like compiler options and library options. DJB handles those by creating little files which the Makefile uses. It is entirely possible to use autoconf in this fashion, and it requires no work beyond what DJB's system requires.
The autoconf system is certainly more complex than DJB's system. I think it is also more powerful and more consistent. It's far from perfect, but I don't think you've clearly identified the problems it has.
I've used autoconf extensively when building with a cross-compiler. Your advice to ``stay far away from autoconf'' is unwarranted.
It's certainly true that building with a cross-compiler requires some extra care. It's also true that autoconf provides somes tests which give errors when building with a cross-compiler. However, it's not arbitrary. Those tests can not be run correctly if you can not run an executable. The tests are provided a convenience for the common case of a program which is never built with a cross-compiler.
For a program which is built with a cross-compiler, there are various ways to handle these tests. I usually write the configure.in script to check the cross_compiling variable, and, if set, perform the check at run time rather than at compile time. For example, if you have the source code to GNU/Taylor UUCP around, look at how the ftime test is handled.
There is a chapter in the book I cowrote which discusses building with a cross-compiler.
Computer technology roughly alternates between centralized control and distributed control. Mainframes to time-sharing to client-server to powerful workstations. Right now we are in a decentralized phase. It makes sense that a centralized phase will come next, and that is what network services are about.
Sure, current implementations aren't fast enough. But there are real benefits to having the app live on a central system. Maybe not to you, but certainly to any large organization.
There are good tests for intelligence, people just don't like what they measure. Intelligence is one of the most reliable psychological characteristics that can be
measured about a person. The correlation between a test given to an individual at one time point, and at a later time point is about 0.80, which is very high for
psychological characteristics.
Huh? Correlation over time is totally beside the point. I think that typical intelligence tests merely test the ability to solve intellectual puzzles under controlled conditions. That's not intelligence. It's a small part of intelligence, granted, but it's not intelligence itself. Correlation over time proves nothing.
Slashdot Mirror
There is no one definition of success for an open source project. Anybody who starts one should have some goals in mind (e.g., hack on cool code, make something which solves a problem for me, make something which is used by 100/1000/1,000,000 people). Success is meeting those goals.
Here are a couple of examples.
I wrote GNU/Taylor UUCP. When I started, success for me was to develop a UUCP package which would be widely used by people without the money to spend on AT&T UUCP, and to be the premier UUCP package on free Unix systems. I met those goals.
I was the GNU binutils maintainer for a few years. During that time, success for me was providing, on multiple platforms, 1) an assembler which could handle whatever gcc generated; 2) a linker which was compatible with the system linker (on a non-free Unix system), and was faster; 3) tools which were very fast on free operating systems--specifically, much faster than gcc so that they were not the bottleneck for development; 4) adding full support for shared libraries. Those goals were only partially met--on Solaris, in particular, the Sun linker was better.
If you don't have any goals, then you can't succeed. If you can't measure your goals, then you can't know whether you have succeeded.
Well, but, 1) Descartes was wrong; 2) even if he were right, a computer program could have sensors which are quite a bit more accurate and wide-ranging than human senses (after all, we already use technology to extend all of our senses), so does that mean that such a program would have a consciousness more real than human consciousness?
Hitler was not elected.
And, although I don't have a convenient link, neither was Hussein. The Baath party took power in a coup, and the elections held since then have been a sham.
Have you been following the Supreme Court lately? They've been coming down in favor of states over the federal government whenever possible.
Besides, if the 'liberated' state can't along without highway funds, then there is something wrong with the whole scheme.
Look at /package.
The states are intervening in a federal case.
My recollection is that the states filed their own case, and Judge Jackson combined it with the federal case.
Wired had a good article about this guy a couple of years back.
To me, spam is unsolicited e-mail. I don't know what sending in bulk has to do with anything. I just care about what winds up in my mailbox.
You're right in that I should have just refused to accept mail from ORBZ. Unfortunately, doing so would have caused me to be listed in ORBZ, and thus caused others to not receive my e-mail. Catch-22: refusing to accept spam would have caused me to be labelled as a spam generator.
My main point, from the post which started this thread, is simply that I believe that ORBZ was acting in a hypocritical fashion, which is a risky position from which to take a moral stand.
It seems to me that a spam e-mailer would make similar arguments. ``You get e-mail you don't want? That's your problem.''
What's the difference?
Is the difference just that ORBZ e-mail testing is good? What if I disagree? I'm sure some spammers think that their e-mail is good. Is their spam OK? Why is ORBZ right and the spammers wrong? Either way I get unsolicited e-mail in my mailbox.
I think they were testing because the messages came from the ORBZ machines.
Sending double-bounce messages is a feature, not a bug. I would be happy to hear an explanation of what I should do to ``fix'' this with respect to ORB* messages.
And in what way was my argument a strawman? Read it again. I didn't say that the ORBZ messages didn't say what they were. I said they didn't tell me specifically why they were testing my server, and I said that they didn't tell me how to prevent receiving those messages in the future.
When one of the open relay testers decides to test my systems (which have never been open relays), I get at least a dozen unsolicited e-mail systems double-bounced to me. Isn't it strange that a system created out of fury at unsolicited e-mail generates a fair amount of it? The double bounce messages never tell me specifically why they have decided to test my system, and they never tell me how to prevent them in the future. Shouldn't people on a moral crusade be careful about hypocrisy?
Sure, modify /etc/rc.d/rc or /etc/rc.d/init.d/functions. If you look in the latter file on Red Hat, you will see that it sets a number of environment variables.
Actually, I got reverse DNS from PacBell DSL, and I know that other people have as well. Send a note to dns-admin@pbi.net.
Lessig isn't saying that all music should be free. He's saying that there needs to be a balance, and that right now the balance has shifted too far toward the copyright holder.
One can imagine an idealized society in which law does not regulate the ability to communicate.
Back in the real world, however, the U.S. government bans certain types of speech for reasons of obscenity (e.g., child pornography), or for reasons of public safety (e.g., incitement to riot), or for reasons of consumer protection (e.g., truth in advertising), or for reasons of commercial value (e.g., DMCA). Not to mention the classification of information for purposes of defense and protection of political reputations.
Those restrictions will change over time, but they are not going to all go away. People who live in the real world need to consider how they should be applied. Just waving them away as philosophically inappropriate means that you can't separate the bad restrictions (IMHO, DMCA) from the good ones (IMHO, truth in advertising).
There may be no digital divide in America, but the focus of the Advogato article is on other countries. There is certainly a digital divide in the world, and there are plenty of people who can not afford a PC no matter how hard they work.
I think the comparison to Starship Troopers is reasonable and appropriate. Starship Troopers was written during the Cold War after World War II and the Korean War, and it reflects the sensibilities of the time (plus Heinlein's own philosophy, of course). I think the Forever War is a conscious updating of Starship Troopers after the country's and the author's experiences in the Vietnam War.
BTW, Haldeman used to teach a science fiction class at M.I.T., and for all I know he still does.
The hardest part of programming is debugging, . . .
That should be true only if you don't design it well and don't use reliable programming techniques.
Do you say that based on your experience with large multi-developer programming projects, or do you say that based on books that you have read? I genuinely want to know.
My statement was based on many years of experience with multi-developer projects, both free and proprietary.
In my experience with software projects, a straightforward build system is essential. It permits consistent builds, which is essential for debugging complex problems. It permits easy builds, which is essential for developer testing. The hardest part of programming is debugging, and good debugging requires speeding up the edit/compile/debug cycle, while ensuring that everybody still gets the same result for each build.
So I would say that no matter what, you should improve your build system.
Given that, should you use the GNU build system, which is autoconf/automake/libtool? Well, it depends. There is a definite learning curve to these tools. They are written in several different languages (sh, m4, perl) and dealing with certain problems can require understanding each of those languages and how they interact. Using these tools will not automatically make your code portable or easy to build; you have to use them correctly, and you have to understand what you are doing.
On the other hand, every other system which supports a complex build process also has a steep learning curve. There's no easy solution--if there were one, everybody would be using it.
The GNU build system is widely used, so there are a lot of people who can help you with it. The mailing lists are active and helpful. There is also a book, but I'm one of the co-authors so you'd better take that with a grain of salt.
I've converted large projects from ad hoc build systems to using the GNU build system. It's usually pretty straightforward--a matter of a week or so--but then I have a lot of experience with the tools.
I've never used most of the other build systems (e.g., Odin, Jam, ANT) for a serious project, so I can't honestly evaluate how they stack up. I can recommend against imake.
As a co-author of a book about Autoconf and friends, I obviously disagree. I don't know why you have trouble using autoconf on Plan 9. I'll just note that I've used autoconf on Windows with the Microsoft C compiler, and it works fine (autoconf does require cygwin to run on Windows, but the programs I built with autoconf did not).
You are certainly correct that autoconf is not going to prevent anybody from writing bad code, such as code littered with #ifdef statements. autoconf is a tool, and it's quite possible to use it poorly.
When you use the AC_CONFIG_HEADER macro, as almost everybody does, autoconf does pretty much what you suggest: the main difference is that it writes a single header file to disk, rather than many small header files.
autoconf normally only changes the Makefile to handle things like compiler options and library options. DJB handles those by creating little files which the Makefile uses. It is entirely possible to use autoconf in this fashion, and it requires no work beyond what DJB's system requires.
The autoconf system is certainly more complex than DJB's system. I think it is also more powerful and more consistent. It's far from perfect, but I don't think you've clearly identified the problems it has.
I've used autoconf extensively when building with a cross-compiler. Your advice to ``stay far away from autoconf'' is unwarranted.
It's certainly true that building with a cross-compiler requires some extra care. It's also true that autoconf provides somes tests which give errors when building with a cross-compiler. However, it's not arbitrary. Those tests can not be run correctly if you can not run an executable. The tests are provided a convenience for the common case of a program which is never built with a cross-compiler.
For a program which is built with a cross-compiler, there are various ways to handle these tests. I usually write the configure.in script to check the cross_compiling variable, and, if set, perform the check at run time rather than at compile time. For example, if you have the source code to GNU/Taylor UUCP around, look at how the ftime test is handled.
There is a chapter in the book I cowrote which discusses building with a cross-compiler.
Computer technology roughly alternates between centralized control and distributed control. Mainframes to time-sharing to client-server to powerful workstations. Right now we are in a decentralized phase. It makes sense that a centralized phase will come next, and that is what network services are about.
Sure, current implementations aren't fast enough. But there are real benefits to having the app live on a central system. Maybe not to you, but certainly to any large organization.
There are good tests for intelligence, people just don't like what they measure. Intelligence is one of the most reliable psychological characteristics that can be measured about a person. The correlation between a test given to an individual at one time point, and at a later time point is about 0.80, which is very high for psychological characteristics.
Huh? Correlation over time is totally beside the point. I think that typical intelligence tests merely test the ability to solve intellectual puzzles under controlled conditions. That's not intelligence. It's a small part of intelligence, granted, but it's not intelligence itself. Correlation over time proves nothing.