How is your counter-theory to the existence of China (replace with any country you haven't been to if you've been to China) coming along? How much work are you putting into it? Or are you just taking the existence of China as a religion?
There's a LOT of evidence in favor of evolution - the same way there is evidence for the existence of China - and no viable replacement theory, nor any path that seems even semi-plausibly to lead to a viable replacement theory. There is, basically, nothing to work on - no reasonable direction towards any theory that isn't a tweaked version of what we have today. And, in my opinion, this is because evolution is true, as true as the existence of China or of chairs.
If the viral GPL gains sufficient foothold, than there will be NO part of the market that is not considered a commodity, and there will be no place for the vast majority of programmers to make any money, and software will die.
That's ignorant. Something like 95% of programmers are employed to write in-house software for their companies to use, and those jobs are perfectly safe from "the viral GPL". The only people who would stand to lose are the ones writing commodity software in the first place.
There's also some user segments that stands to lose.
In the present market, groups pay for enhancements from a baseline - the present codebase. This is done after the product is developed, by buying the product, and thus the users do not need to take the risk around the development. Users choose to do this when the benefit to them of using the software exceeds the costs of purchasing the software.
With purely GPLed software, users cannot do this. Instead, they have to organize banding together, raising money up front (with the free rider problem meaning that a lot of people won't pay), hire a programmer or programmer team, and then take the risk of whether those programmers will perform.
At least to me, it seems obvious that there will be many cases where users will not do this - and in practice will lose access to the software they could get benefits from.
see it as the system working as designed. Microsoft isn't "getting away" with anything - they're accepting an offered gift and using it like the givers hoped they would.
If that's what I want, I can (and have in the past) do it better by releasing the software into the Public Domain. BSD licenses tend to have annoying little attribution and advertising clauses and whatnot.
The reason many BSD advocates do not use public domain licenses is that we want to avoid getting sued. Public domain seems to open up a can of worms, legally speaking.
Also, there's some emotional issues involved: While you may feel it OK for others to use your work and earn money from their enhancements, it may still feel bad if they get the credit for your work, too.
Do you prefer that the users do not get to get the benefit of your code at all rather than getting some benefit from it?
Are you willing to remove the chance that somebody will make a proprietary version and give you back those of the changes they can (which are often most) just to remove the chance that somebody will use your codebase (instead of somebody else's codebase) as the basis for their proprietary product and give nothing back?
Will you mind denying the possible end users of your code the benefit of using standard economic tools to get rid of risk (having somebody take the risk of researching something and then paying for it after the research is successful) just for your philosophy?
I prefer the BSD license because I see it as giving users more freedom. I see the GPL working by removing the use for the users that wouldn't have freedom. With a brutal metaphor: It is sort of like bombing a political prison to make sure there are no political prisoners. It accomplishes the goal in a literal fashion - but a more careful analysis has led at many of us to conclude that it is in the way of our real goals.
I understand how you reach this conclusion. Alas, the benefit you assume is based on assumptions that hold in far from all situations.
There's a hidden assumption here.
This that people that make derivative works from BSD code do not give away any of their changes. This assumption is wrong, both for proprietary derivative works and for other derivative works. For other open source derivative works, all code is naturally available. For proprietary derivative works, changes basically end up in two classes: Tactical (we do this because we need the functionality) and strategic (gives significant competitive advantage). Tactical changes will often (usually?) be contributed back to the BSD code base, as donating back gives several benefits: The community helps with maintenance (both avoiding incompatible changes and sometimes doing extensions to the code), you gain community goodwill and can often get help from the community (even for proprietary things), you avoid merge conflicts, and the programmers feel good about contributing to the open source version. The net effect of all these benefits is major contributions back.
And, with that assumption gone, the conclusion - that the BSD trade is giving code for nothing - should be gone, too. We (at least partially) give code for code - we've just discovered that we get more code back by letting the user do whatever they need to do, because restricting them makes them go play with something else, something where they can't give us anything at all.
A good design should be independent of implementation constraints.
A design is chosen as a compromise between different implementation constraints, most of which are possible to negotiate and sort of soft. A good design is one the choose a compromise that maximize goal reaching for the system in question.
One such goal would usually be solving some business problem. Other goals could include minimizing training time, making it easy to recruit people to work on the system, making the system live for a certain amount of time (including porting costs etc), hitting certain response times, being able to support certain usecases, hitting certain delivery deadlines, etc, etc, etc.
Which of these goals are most important depends on the situation. And again: The job of the software designer (I loathe the term "architect") is to trade off between them in an optimal way for the present situation. Saying that some of them should always be ignored is extremely arrogant towards the people that actually need those requirements met to have their day to day work be reasonable - whether that's the manager that needs to be able to get the system at a certain time, or the programmer that shouldn't be forced to work against the tools and systems available.
You are asking what design/architecture qualities are shared by all great software, with a definition of great software.
I believe the question is wrong. Because there are many ways to reach maintainable/solid software, there are likely no qualities beyond those you list shared by all such software. Most, maybe, but not all.
Let me start with a question: Do you actually know how species are defined among bacteria?
Because by the common definition of E.Coli, inside how we define species in bacteria, they are NOT E.Coli after this. You can argue against this, of course, but then you need to actually go into how we do species definitions among bacteria, and come with an alternative way of doing classification and argue why this way is (A) a reasonable substitute for the present method, and (B) gives your claimed result.
...sure to perplex and confound creationists...
Not really. They're still bacteria. Obviously bacteria can evolve different traits. ... but in this case they've evolved different traits that turn them into a different species. And, because creationists seems to usually not get what species are, they think that "switching species" is a particular boundary...
Eivind, who happens to have investigated evolution and therefore understand that creationists haven't.
You also know that science had been around for thousands of years without being "threatened", right?
No.
You're misinformed.
Science, in the sense we use the word (a communal, systematic investigation of the world with a focus on disproving hypotheses), hasn't been around for thousands of years; it's been around since the late 1600s, and it's derived from the *single* case where this started occurring before - the Greek debate.
And, what's blocked us before this has been "magical thinking", with religion as one of the forms this show up in.
For a long, sourced discussion of this, check out "Uncommon Sense" by Alan Cromer.
I'm not quite ready to embrace evolution as the origin of species (as opposed to evolution within species, which I do accept) I come across this viewpoint a lot among what I otherwise perceive as wise, open-minded Christians, so I'd be curious if you'd answer a question for me: What would it take for you to accept evolution as the origin of the species?
I'll note that to me, evolution as the origin of the species is the obvious conclusion - I've seen scores of types and hundreds of pieces of evidence for it, and no evidence that goes in the opposite direction. But, for you, there's obviously things that you feel hard to reconcile - and I'd like to know what they are.
I find the following convincing evidence: Because not having this ability is considered a definition for their species, and because of the complexity of the mutation involved (20k generations for baseline + 10k generations to find the ability afterwards), and because 11 other populations hasn't been able to find this ability.
To be honest, somebody who needs to get a job done nearly cares squat whether a tool is free or costs 300$. It's only because the 300$ tools are just as crappy as the free ones (sic!) that they settle for the free ones. And damn the few bucks I have to shell out for it. Personally, I usually go for the free ones because they come with a several major features:
I can fix up minor stuff that get in the way if I have to (including the existence of a community that's positive around this and can accept fixes back). This is a big insurance - I don't have to do it that often, but it makes me comfortable.
The free tools are generally nicely packaged for the operating systems I use (through FreeBSD ports or Linux packaging systems or as Mac DMGs)
There is no hassle around licensing. We're both allowed to do what we want to do without getting more permission, and there's not copy protection to get in the way.
There is a community that gives good support.
The money in itself is of fairly little importance; we're spending a lot of money on salaries and servers and bandwidth and offices, so throwing in a few thousand (or tens of thousands) here and there for software would not be that big a deal. However, the money should be well spent - and missing the features above often makes the commercial offerings worse than the free ones.
Specific arrogance showing up again, eh? After all your mumbo-jumbo attacks?
Tell me, are you one of these only-C++-and-Java experienced people that feel like judging the world based on their own lack of experience - based on their own fear?
You sound that way. And you sound horribly arrogant in your communication.
As do probably I, right now - and that's because your choice of staying in your little stupid corner and shouting "I KNOW EVERYTHING I CAN ATTACK EVERYBODY I DON'T NEED TO LEARN LAH LAH LAH LAH I HAVE MY FINGERS IN MY EARS SO I DON'T HAVE TO HEAR YOU" is fairly annoying to those of us - or at least those of me - that actually have spent a couple of decades inside different forms of code, and actually know how to program concepts in different languages.
you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
ROFL. That made me laugh! Good stuff. Objects in C! Yes, this is common. I actually see it used in some subsystems in most large C projects. To continue the example above, the file system interfaces in BSD kernel (I don't know the Linux kernel too well) is written using an object-oriented model in C, including an extensible operations table (similar to a vtable in C++, but possible to extend at runtime when you load a new filesystem.)
And C++ is crap for OO stuff! LMFAO! Was that a joke? That guy doesn't have a clue... You're fairly arrogant here. I'll point you at a description of OOP by Alan Kay, the inventor of OOP, and I'll offer up this quote of his:
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind." (From "The Computer Revolution hasn't happend yet", his keynote at OOPSLA 1997)
C++ has strengths and weaknesses - and, if you're skilled, you will recognize this.
The fact that the Linux and Microsoft kernels are written in C does not change these facts:
- C++ has all capabilities and features as C C++ miss the feature of C of being relatively transparent in terms of what is going on when you've compiled it.
C++ also miss the capability of being quickly compiled by a reasonable free compiler (g++ was slow as molasses the last time I checked.)
And, C++ has a smaller programmer base: All good C++ programmers should be able to program C fairly well, while not all C programmers are good C++ programmers.
Whether this is important enough to make it a good choice to write a kernel in C instead of C++ is of course debatable - I just want to point out that there are reasonable arguments on both sides. (I personally tend to lean towards the C side, but much less so than I used to.)
That takes me back to the horror of 15 years or so ago when I was working with pre-'option explicit' VB. Where typos could cause completely unpredictable (and rare/intermittent) strange side effects.
That kind of thing is so hard to troubleshoot, just makes me want to tear my hair out. That doesn't happen in practice, at least not for me. In practice, I spend very little of my development time fixing things that could have been prevented by type checking. This is true even in Perl (where I, for historical and employment reasons, do most of my coding), which in my experience is worse in this area than Ruby.
"Very little" means in the order of 1%. It's not at all significant compared to the time I save from being able to deal with better abstractions.
C is perfectly capable of many of the most useful object oriented techniques.... All the while, the programmer can remain in complete control,
I've programmed C for a decade and a half, including writing object systems in it, and writing memory management systems for it.
If you want complete control, you should be programming in assembly language on a microcontroller.
C gives up a noticable bit of control in order to make things more convenient; C with memory management gives up a LOT of control to make things more convenient.
Also, in practice, the C programmer gives up control of his program to the program itself - the increased size of the program makes it less convenient to change, and thus remove some real control.
This isn't just playing at semantics - this is a really important point, as you are talking about:
and the application can remain fast and lightweight. To get a fast and light application, you should be profiling your app, both in where it spends time and where it spends memory. 99% of the time 90% of your app is going to be insignificant in both time and space, and you can optimize the rest to get speed and low memory consumption. With a language where you have less hassle than C, you have more time to optimize this, assuming the static runtime for the language you write in isn't too large in itself, and the startup cost isn't too large.
Now, there *are* cases where the average time spent will kill you. I've had one such case for trying to write a music synthesizer in Ruby. I ended up with time spent all over the place, and no hotspots that were possible to optimize. However, 99% of the time, you can get away with writing in a high level language instead of C, and patching in C where it may be necessary for high performance (under an assumption that you're not writing core libraries/kernels for things that do massive data processing.)
I agree that hit actors are generally overpaid. However, I think we should also remember that acting actually is skilled work taking years to learn - and that voice acting is hard, possibly harder than general acting. I would guess video game voice acting is among the easier parts, though - it's disconnected parts, and don't usually convey that much emotion.
There is nothing about copyright law that cripples any business model that chooses not to rely on copyright. I'm in favor of copyright (though with shorter terms than today), as it leads to production of more works.
And while the above quote seems reasonable at first reading, I think it's incorrect in practice. There two issues that work against an artist not using copyright in a culture where copyright is enforced:
First, for popular culture copyright tend to centralize a lot of money. This money is used to advertise, which reinforce the concentration. This makes it hard for somebody outside that run to get by without joining in that money pump, even when they'd be perfectly fine if they didn't have to compete against expensively advertised acts.
Second, copyright removes cultural commons. Disney built their empire on Snow white and Cinderella - cultural commons from the previous age. These days, the common culture is copyrighted - so there is less cultural commons to draw from. Everything everybody knows is copyrighted.
As I said: I believe copyright is still worthwhile. I just think we should be aware of the full costs.
If the counterfeiter just put the copies of money in their bathtub and played Scrooge McDuck with it, that would be the equivalent of enjoying the illegal files. Spending it is about getting a service from somebody else, as money is a store of value/time.
Also, most people DO just stick their illegal files on their hard drives, or at least many of those files (probably most). Pirates, at least those of my aquitance, tend to be collectors, getting a bunch of stuff that they're "Going to check out real soon now".
If it's a kernel driver for the Skype protocol, that could be a problem for them. (I personally think that protocols used be the public should never be proprietary - but they still could see it as a problem, as they're trying to keep that protocol secret.)
Slashdot Mirror
The Morris Worm, which introduced stack smashing as a technique, was in 1988. That was what the article you replied to was talking about.
There's a LOT of evidence in favor of evolution - the same way there is evidence for the existence of China - and no viable replacement theory, nor any path that seems even semi-plausibly to lead to a viable replacement theory. There is, basically, nothing to work on - no reasonable direction towards any theory that isn't a tweaked version of what we have today. And, in my opinion, this is because evolution is true, as true as the existence of China or of chairs.
Eivind.
If the viral GPL gains sufficient foothold, than there will be NO part of the market that is not considered a commodity, and there will be no place for the vast majority of programmers to make any money, and software will die.
That's ignorant. Something like 95% of programmers are employed to write in-house software for their companies to use, and those jobs are perfectly safe from "the viral GPL". The only people who would stand to lose are the ones writing commodity software in the first place.
There's also some user segments that stands to lose.
In the present market, groups pay for enhancements from a baseline - the present codebase. This is done after the product is developed, by buying the product, and thus the users do not need to take the risk around the development. Users choose to do this when the benefit to them of using the software exceeds the costs of purchasing the software.
With purely GPLed software, users cannot do this. Instead, they have to organize banding together, raising money up front (with the free rider problem meaning that a lot of people won't pay), hire a programmer or programmer team, and then take the risk of whether those programmers will perform.
At least to me, it seems obvious that there will be many cases where users will not do this - and in practice will lose access to the software they could get benefits from.
Eivind.
Eivind.
If that's what I want, I can (and have in the past) do it better by releasing the software into the Public Domain. BSD licenses tend to have annoying little attribution and advertising clauses and whatnot.
The reason many BSD advocates do not use public domain licenses is that we want to avoid getting sued. Public domain seems to open up a can of worms, legally speaking.
Also, there's some emotional issues involved: While you may feel it OK for others to use your work and earn money from their enhancements, it may still feel bad if they get the credit for your work, too.
Eivind.
Do you prefer that the users do not get to get the benefit of your code at all rather than getting some benefit from it?
Are you willing to remove the chance that somebody will make a proprietary version and give you back those of the changes they can (which are often most) just to remove the chance that somebody will use your codebase (instead of somebody else's codebase) as the basis for their proprietary product and give nothing back?
Will you mind denying the possible end users of your code the benefit of using standard economic tools to get rid of risk (having somebody take the risk of researching something and then paying for it after the research is successful) just for your philosophy?
I prefer the BSD license because I see it as giving users more freedom. I see the GPL working by removing the use for the users that wouldn't have freedom. With a brutal metaphor: It is sort of like bombing a political prison to make sure there are no political prisoners. It accomplishes the goal in a literal fashion - but a more careful analysis has led at many of us to conclude that it is in the way of our real goals.
Eivind.
There's a hidden assumption here.
This that people that make derivative works from BSD code do not give away any of their changes. This assumption is wrong, both for proprietary derivative works and for other derivative works. For other open source derivative works, all code is naturally available. For proprietary derivative works, changes basically end up in two classes: Tactical (we do this because we need the functionality) and strategic (gives significant competitive advantage). Tactical changes will often (usually?) be contributed back to the BSD code base, as donating back gives several benefits: The community helps with maintenance (both avoiding incompatible changes and sometimes doing extensions to the code), you gain community goodwill and can often get help from the community (even for proprietary things), you avoid merge conflicts, and the programmers feel good about contributing to the open source version. The net effect of all these benefits is major contributions back.
And, with that assumption gone, the conclusion - that the BSD trade is giving code for nothing - should be gone, too. We (at least partially) give code for code - we've just discovered that we get more code back by letting the user do whatever they need to do, because restricting them makes them go play with something else, something where they can't give us anything at all.
Eivind.
A good design should be independent of implementation constraints.
A design is chosen as a compromise between different implementation constraints, most of which are possible to negotiate and sort of soft. A good design is one the choose a compromise that maximize goal reaching for the system in question.
One such goal would usually be solving some business problem. Other goals could include minimizing training time, making it easy to recruit people to work on the system, making the system live for a certain amount of time (including porting costs etc), hitting certain response times, being able to support certain usecases, hitting certain delivery deadlines, etc, etc, etc.
Which of these goals are most important depends on the situation. And again: The job of the software designer (I loathe the term "architect") is to trade off between them in an optimal way for the present situation. Saying that some of them should always be ignored is extremely arrogant towards the people that actually need those requirements met to have their day to day work be reasonable - whether that's the manager that needs to be able to get the system at a certain time, or the programmer that shouldn't be forced to work against the tools and systems available.
Eivind.
I believe the question is wrong. Because there are many ways to reach maintainable/solid software, there are likely no qualities beyond those you list shared by all such software. Most, maybe, but not all.
Eivind.
Because by the common definition of E.Coli, inside how we define species in bacteria, they are NOT E.Coli after this. You can argue against this, of course, but then you need to actually go into how we do species definitions among bacteria, and come with an alternative way of doing classification and argue why this way is (A) a reasonable substitute for the present method, and (B) gives your claimed result.
Eivind.
Eivind, who happens to have investigated evolution and therefore understand that creationists haven't.
You also know that science had been around for thousands of years without being "threatened", right?
No.You're misinformed.
Science, in the sense we use the word (a communal, systematic investigation of the world with a focus on disproving hypotheses), hasn't been around for thousands of years; it's been around since the late 1600s, and it's derived from the *single* case where this started occurring before - the Greek debate.
And, what's blocked us before this has been "magical thinking", with religion as one of the forms this show up in.
For a long, sourced discussion of this, check out "Uncommon Sense" by Alan Cromer.
Eivind.
I'll note that to me, evolution as the origin of the species is the obvious conclusion - I've seen scores of types and hundreds of pieces of evidence for it, and no evidence that goes in the opposite direction. But, for you, there's obviously things that you feel hard to reconcile - and I'd like to know what they are.
Eivind.
Eivind.
- I can fix up minor stuff that get in the way if I have to (including the existence of a community that's positive around this and can accept fixes back). This is a big insurance - I don't have to do it that often, but it makes me comfortable.
- The free tools are generally nicely packaged for the operating systems I use (through FreeBSD ports or Linux packaging systems or as Mac DMGs)
- There is no hassle around licensing. We're both allowed to do what we want to do without getting more permission, and there's not copy protection to get in the way.
- There is a community that gives good support.
The money in itself is of fairly little importance; we're spending a lot of money on salaries and servers and bandwidth and offices, so throwing in a few thousand (or tens of thousands) here and there for software would not be that big a deal. However, the money should be well spent - and missing the features above often makes the commercial offerings worse than the free ones.Eivind.
Eivind.
Tell me, are you one of these only-C++-and-Java experienced people that feel like judging the world based on their own lack of experience - based on their own fear?
You sound that way. And you sound horribly arrogant in your communication.
As do probably I, right now - and that's because your choice of staying in your little stupid corner and shouting "I KNOW EVERYTHING I CAN ATTACK EVERYBODY I DON'T NEED TO LEARN LAH LAH LAH LAH I HAVE MY FINGERS IN MY EARS SO I DON'T HAVE TO HEAR YOU" is fairly annoying to those of us - or at least those of me - that actually have spent a couple of decades inside different forms of code, and actually know how to program concepts in different languages.
Eivind.
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind." (From "The Computer Revolution hasn't happend yet", his keynote at OOPSLA 1997)
C++ has strengths and weaknesses - and, if you're skilled, you will recognize this.
Eivind.
C++ also miss the capability of being quickly compiled by a reasonable free compiler (g++ was slow as molasses the last time I checked.)
And, C++ has a smaller programmer base: All good C++ programmers should be able to program C fairly well, while not all C programmers are good C++ programmers.
Whether this is important enough to make it a good choice to write a kernel in C instead of C++ is of course debatable - I just want to point out that there are reasonable arguments on both sides. (I personally tend to lean towards the C side, but much less so than I used to.)
Eivind.
"Very little" means in the order of 1%. It's not at all significant compared to the time I save from being able to deal with better abstractions.
Eivind.
C is perfectly capable of many of the most useful object oriented techniques. ... All the while, the programmer can remain in complete control,
I've programmed C for a decade and a half, including writing object systems in it, and writing memory management systems for it. If you want complete control, you should be programming in assembly language on a microcontroller. C gives up a noticable bit of control in order to make things more convenient; C with memory management gives up a LOT of control to make things more convenient. Also, in practice, the C programmer gives up control of his program to the program itself - the increased size of the program makes it less convenient to change, and thus remove some real control. This isn't just playing at semantics - this is a really important point, as you are talking about: and the application can remain fast and lightweight. To get a fast and light application, you should be profiling your app, both in where it spends time and where it spends memory. 99% of the time 90% of your app is going to be insignificant in both time and space, and you can optimize the rest to get speed and low memory consumption. With a language where you have less hassle than C, you have more time to optimize this, assuming the static runtime for the language you write in isn't too large in itself, and the startup cost isn't too large. Now, there *are* cases where the average time spent will kill you. I've had one such case for trying to write a music synthesizer in Ruby. I ended up with time spent all over the place, and no hotspots that were possible to optimize. However, 99% of the time, you can get away with writing in a high level language instead of C, and patching in C where it may be necessary for high performance (under an assumption that you're not writing core libraries/kernels for things that do massive data processing.)Eivind.
Eivind.
And while the above quote seems reasonable at first reading, I think it's incorrect in practice. There two issues that work against an artist not using copyright in a culture where copyright is enforced:
First, for popular culture copyright tend to centralize a lot of money. This money is used to advertise, which reinforce the concentration. This makes it hard for somebody outside that run to get by without joining in that money pump, even when they'd be perfectly fine if they didn't have to compete against expensively advertised acts.
Second, copyright removes cultural commons. Disney built their empire on Snow white and Cinderella - cultural commons from the previous age. These days, the common culture is copyrighted - so there is less cultural commons to draw from. Everything everybody knows is copyrighted.
As I said: I believe copyright is still worthwhile. I just think we should be aware of the full costs.
Eivind.
Also, most people DO just stick their illegal files on their hard drives, or at least many of those files (probably most). Pirates, at least those of my aquitance, tend to be collectors, getting a bunch of stuff that they're "Going to check out real soon now".
Eivind.
Eivind.